Uncovering Scrum Myths: User Story
Are you new in the IT industry and scared of some unknown phrases and weird slang? Or you have longstanding experience as a software developer but you want to refresh your knowledge? All reasons to learn something new are good! Let’s see what the most common misunderstandings in software development world are these days. All myths needs to be uncovered! At the beginning let’s talk about User Story.
In my day to day, I see quite often that user stories may bring a lot of confusion even for qualified professionals. Product Owners tend to create them in either too detailed or too laconic a way. Developers working with user stories usually think technically and forget about business context. Testers are in very straitened situation trying to test badly prepared user stories. That’s why I think it’s useful to recall what user stories really are and what you should pay attention to when you create them.
To be as simple as possible – a user story is just a way of storing and presenting requirements. It’s a very clear and flexible way. As agile methodologies are getting more and more prevalent, there is a need to have agile tools as well. In an uncertain environment when you need to follow customer needs, it’s really important to have flexible tools that allow you to quickly react on changes. That’s why lightweight user stories fits better nowadays than chunky formalised documents (and formalised approval processes coupled with them!) that were still popular not so long ago.
There are several conditions that should be met to consider a few lines of text you has just written as a good user story. First of all, think about business value. Why does the customer want to pay you? Because your software will solve their problem! So basically solving problems gives your customer some value. We can then say that Business Value is every reason why your customer wants to pay you. It can be either increasing profit, reducing risk, making employees feel better or some other form of needs and expectations. Every good user story should bring Business Value to your customer. Otherwise your effort will be wasted.
The next thing that should be assured for each user story is independence. The development team needs to be able to pick up a task and start working as soon as user story is added to the sprint. In my experience I have seen a lot of frustrating situations when one user story was dependent on another one. The team wanted to start working but were blocked. The best way to not block the work of your team is to think about dependencies before you even start creating your story. The earlier dependencies are solved, the more efficient your team can work!
And the last thing – user stories should be based on real life scenarios. The worst thing that you can handle during development is working on a scenario that makes no sense or couldn’t happen in real life!
The main idea behind user stories is to define one scenario of user journey in the system. That’s all! To make it more readable we can give it a structure. The most popular is the scheme:
As a <role> I want to <some goal> so that <some reason>.
Why is this scheme so good?
I really encourage you to start from defining roles in your system. The role represents a group of users (not to be considered as individuals!) and based on their interests in the system, and what they may potentially use it for. After that, think about the effect you want to achieve. Why is more important than what. When you know who the subject is and what motivations are, take piece of paper (e.g. sticky note) and start writing. Sticky notes can be easily stuck to the board giving you possibility to organise them in prioritised backlog.
No! Consider your user story as a starting point for discussion. You don’t need to know everything at the beginning. Feel free to modify your stories every time you have new information, new ideas or whatever! Start from high level and keep providing details over time. The good rule is that stories that are at the top of your backlog (so they are close to being kicked-off) should have more detail, while stories that are not clarified yet and are at the bottom may have just high level descriptions. You will expand them later.
The first step that you can do to make user story better is adding acceptance criteria. That are all things that need to be met to view work as completed. The user story, by definition, is simple and focused on user needs. To make it more readable and substantial for technical people (developers, testers, etc…) consider attaching list of some further, more detailed suggestions. In a form of bullet points, you can encapsulate any more specific requirements:
A good starting point for defining acceptance criteria is showing the user story to your development team. Answers to all questions they would have will form your first set of acceptance criteria. Please remember that good acceptance criteria should be specific and measurable, so people can rely on them.
The last section of this blog may lead you to think that you should always expand your user story. Is it true? Absolutely not! Developers need to have all non-obvious points clarified to be able to deliver what is expected. But you don’t have to swell your story to infinity. Keep it simple! Stories that are too long can become a nightmare. To conclude whether your story is too big or perfect fit try to ask several questions:
If answer to any of these questions is no, that’s good starting point to think about splitting the story into multiple stories! How to do it is a topic for another blog post and there is no simple answer, but try to focus on splitting by functionalities (vertically) and avoiding dividing by technical layers (horizontally) to keep user story having business value, being testable and estimate-able.
Small stories are easier to estimate, implement and test, giving development team higher chance of completing them within one iteration and giving you more flexibility on prioritising and planning.
This article was originally published here.
September 2016
July 2017