User stories… in the agile environment everybody is talking about them. And almost everybody is writing them, or at least trying to.
I’ve written hundreds, maybe thousands of user stories. They weren’t all great, especially in the beginning of my career. But over time the stories became better and better, because I never stopped learning from colleagues, team members, blogposts and so on. The feedback I got from my teams made me write this post for people who want to read and learn a few tips and tricks for writing better user stories. Or if you are just starting your career as a Product Owner, Business Analyst or any other position in which you’re writing stories, this post could be helpful.
User stories are written for evoking a conversation with development teams in order to create a product.
The right product.
If you want the right product, you need the right user stories sorted by the correct priority.
I’ve seen many backlogs containing one-liner user stories. The Product Owner lets the team struggle with these stories and problems of various kind emerge very quickly. One line is just not sufficient for developers, designers and testers to start working on these items. Lacking information is, in my opinion, one of the biggest reasons for slow progress of projects, incorrect interpretation, rework, unhappy stakeholders, etc.
You can avoid these problems by adding more information. And let me state this up front: adding more information is still agile!
When the story contains enough information, the conversation will be efficient and to the point.
So, what do I do to create good user stories? Stories that contain sufficient information for development teams to work on? Stories that reflect the correct business needs and are easy to understand by any involved person.
Let me start with the basics.
A user story is just a notation for requirements. Period.
Is looks like this:
| AS | persona |
| I WANT | functional wish |
| SO I CAN | do something that has value |
| WHEN | conditions for this story |
Persona is the user concerned.
The functional wish is the core of the story. I want to emphasise that it is a value-adding functional wish. Not a solution!
The team will look for a solution for the functional wish or problem. If there is more than one solution possible, you can help choose the most suitable one. The one that adds the most value in the shortest period of time, the one that has the best future-proof characteristics, the one that required the least dependencies, etc.
The last part of the story makes the feature applicable. When should the user be able to use this feature? After logging in? When there is an incoming call? If a certain skill is required? Don’t forget this last bit of important information.
The basics are pretty simple. What’s next?
I ask myself questions like:
- What type of story is this? Is it about a feature, which is part of an epic? Or is it a bug, or maybe part of some technical debt that needs to be resolved?
- When can I accept this feature and deliver it in production?
- What are the requirements regarding performance, availability, responsiveness and documentation?
- What exactly is the value we’re adding here? Business value? If so, what it is? What if we don’t deliver this feature? What’s the cost of delay?
- Are there any dependencies related to this story? Do we need another team or an architectural change? Will we need an expert from the business at a certain moment?
- What if the system goes down? How is the team alerted? Should we monitor the systems behaviour to avoid outages?
- Any other requirements? Like time constraints, compliance or security, feature toggling, user training, handover to operations, etc?
By asking the business, yourself and the team, many of these questions, the user story will be more complete over time, and eventually ready for a sprint. The user story is now to the point, small enough to be comprehended by everybody, easy to change and thus very agile.
I’ve created a User Story Template document with many of my questions. This list of questions will never be complete, it is just a tool you can use when writing user stories and refining them with the business and your team. Not every question may be applicable to your organisation or project, but many are.
You can find my User Story Template down here. You’re free to use it. Just fill in your name and email.
