Are you new in 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 daily work I see quite often that user stories may bring a lot of confusions even for qualified professionals. Product Owners tend to create them in either too detailed or too laconic 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.
User what? What on earth is User Story?
To be as simple as possible – user story is just a way of storing and presenting requirements. And it’s very clear and flexible way. As agile methodologies are getting more and more popular nowadays, there is a need to have agile tools as well. In 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 fat formalized documents (and formalized approval processes coupled with them!) that were still popular not so long ago.
What makes user story good?
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 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 all reasons (benefits!) why your customer wants to pay you. It can be either increasing profit, reducing risk, making employees feel better or any 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. Development team needs to be able to pick up this 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. Team wanted to start working but was 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 story should be based on real life scenario. The worst you can handle during development is working on scenario that has no sense or is impossible to happen in real life!
Okay, but how User Story should look like?
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?
- It’s easily manageable as all requirements have the same format – great benefit when you prioritize features in the Backlog.
- It provides a role in the system as you can have different types of users with different needs and different scenarios
- It defines expected behaviour and emphasizes the reason, giving the team better understanding, highlighting value and business benefits and reducing the chance of implementing unnecessary features
How can I start writing User Stories?
I really encourage you to start from defining roles in your system. Role represents group of users (should not be considered as individuals!) and bases on their interests in the system. 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 organize them in prioritized backlog.
Photo: Sample scrum board (prepared by author of this post) with user stories
Wait! Do I need to know what user wants up front?
No! Consider your user story as a place 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 start implementing them) should have more details while stories that are not clarified yet and are at the bottom may have just high level descriptions. You will expand them later.
I wrote first user stories. How can I polish them?
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. 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 encapsulate any specific requirements like:
- All technical boundaries
- All cosmetic details (colours, designs, etc…)
- All non-obvious behaviours
- All very specific circumstances and conditions
- All things that potentially may help in development
- All information needed for testing
Good starting point for defining acceptance criteria is showing the user story to 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 bigger story the better?
Paragraph above may lead you to thinking 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. Enough is enough! Too big stories are nightmare. To conclude whether your story is too big or perfect fit try to ask several questions:
- Does the story cover only one particular feature/requirement/user journey?
- Is the story small enough to fit in one sprint?
- Is the story easy to estimate?
- Is the work that needs to be done separable and independent?
If answer to any of these questions is no, that’s good starting point to think about splitting the story! How to do it is a topic for another blog post and there is no simply 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 estimable.
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 prioritizing and planning.
That’s all Folks!
Is now another myth uncovered? I hope this article was useful for you. It doesn’t say everything and just touches the topic, so I encourage you to explore it further and listen to the team. People always know what works best for them.
If you have any questions or other point of view on creating good user stories, share it in comments. Discussion is always welcome!
- Feliński, Paweł. Before the first sprint. Workshop at Agile By Example 2015
- Jarrel, Jeremy. Creating effective user stories. Course on Pluralsight (https://www.pluralsight.com/courses/creating-effective-user-stories)
- Krupa, Łukasz. Refine your backlog first. Workshop at Agile By Example 2015