What Not to Do With User Stories
It’s never about writing better requirements; it’s all about fostering collaboration.
It’s never about writing better requirements; it’s all about fostering collaboration.
Did you know that most Scrum Teams in the world work with User Stories? Yet, several misconceptions hold teams back from thriving. I’ve stumbled upon some questions that lead teams in the wrong direction, for example:
How can I write better User Stories?
How can I provide more detailed requirements for the developers?
How can we get better estimates with User Stories?
Well, it’s never about writing better User Stories. It’s also not about defining precise requirements. User Stories are a tool to foster collaboration and ensure we don’t forget the most critical part of any product or service: The End-User.
I’ve committed countless mistakes with User Stories. That’s why I’d like to share with you some of my learnings of what NOT to do with User Stories. Hopefully, you can use User Stories to solve the end-users’ real problems.
Recently, I shared a video about what NOT to do with User Stories on my YouTube channel. If you are interested, please watch the following video.
User Story is NOT a Solution to Implement
For years, I wrote extensive software specifications. I had to ensure developers had all the required information to implement the specified solution. I didn’t care if they understood the problem. Implementing the solution correctly was the ultimate goal. Regardless of all the effort we put into it, stakeholders and customers weren’t satisfied because we failed to solve their problems.
When I started working with User Stories, I misused them. I thought they were a tool to represent the requirements. As a Product Owner, I wrote as many User Stories as I could. They were solutions to implement instead of problems to solve. Still, customers and stakeholders were unhappy with the results.
User stories are not tasks. In fact, a single story may need hundreds of single tasks to be successfully delivered. Tasks are about implementation; user stories are about definition.
— George Krasadakis, How (and Why) to Write Great User Stories
I learned a crucial lesson, if you don’t change your mindset, no matter which process or tool you use, the results will be very alike. First, you should change your mindset; then, you can get different outcomes.
Great User Stories produce an excellent conversation. The result is clarity on how to solve the users’ problem.
Bad User Stories focus on estimating a solution to implement. The result is an estimate of a solution to implement. The problem remains unknown to the team.
Do Not Ignore the Conversation with the Team
Nowadays, we have dozens of tools to manage the Product Backlog. Some examples are: Jira, Trello, Asana, and so on. It’s easy to fall into many pitfalls. The most common is to let tools drive our actions. We have to remember that such tools are no more than a means to an end.
“Individuals and interactions over processes and tools“
User Stories were conceived to solve a serious problem: ensure developers understand what the end-user needs. Simplicity was the core when Kent Beck coined the term. The User Story is a compound of three parts:
Card: the story written from the end-user perspective. Who, what, and why are clear. The card is no more than a reminder of a conversation. You have a limited space only to write what matters the most.
Conversation: before implementing a solution, developers take the card and discuss it with the end-user to understand the needs.
Confirmation: during the conversation, developers define how to confirm the problem has been solved. Then, they write down what is known as the acceptance criteria.
That’s how User Story should be used, but that’s not the case with many Scrum Teams. A typical scenario would be like the following:
The Product Owner writes the User Story as detailed as possible on a tool like Jira. The acceptance criteria are precisely defined.
The Scrum Team refines the User Story. The goal is to gain clarity on the solution to implement. The Scrum Team might reshape the acceptance criteria.
After the solution is clear, the developers estimate the User Story.
That’s not how User Story should be used. Until the Scrum Team understands the problem, they are not ready to discuss the solution. Product Owners should not focus on defining solutions to implement; they should focus on building a shared understanding of a problem that is worthwhile to solve.
First comes the problem, then the solution. How can a Product Owner write all acceptance criteria upfront? The confirmation is the third part of User Stories, which should only happen after the team's conversation, not before.
User stories were coined many years ago when Kent Beck defined eXtreme Programming (XP). The goal was far less about the actual format and more about the intent — to tell a story. A story of our customers, articulating the who, what and the why.
Don’t Force Everything into User Stories
Although User Stories are familiar among Scrum Teams, they are not mandatory. You should keep your Product Backlog Items in the format that works best for your team. It’s OK to combine User Stories with another format.
You should not worry a lot about the Product Backlog Items’ format. The most important aspect is to ensure they are no more than a reminder for a conversation. Please don’t treat the Product Backlog Items as requirements; treat them as invitations for conversations.
So there’s absolutely nothing wrong with User Stories. They are a great technique for capturing functional requirements in a ‘good enough for now’-manner that leaves room for further conversation. But Scrum doesn’t prescribe nor require them.
— Christiaan Verwijs, Myth: In Scrum, the Product Backlog has to consist of User Stories
I believe User Stories work well when we have a problem to solve or an opportunity to benefit from. They foster collaboration and help the Scrum Team build the needed shared understanding to move forward.
I don’t think User Stories work well for tasks or bugs. From my experience, it doesn’t seem natural to write bugs or tasks with the User Story format. In my opinion, User Stories were not designed to handle bugs or tasks. That’s why forcing bugs or tasks into User Stories causes a pointless overhead.
Whenever you think you are mechanically following a process, it’s a sign you should reflect on it. Are you following the process because you are used to it or because it’s the best way to get to the result you want?
User Story is no more than a technique to foster collaboration. It’s not a process to follow.
Final Thoughts
Your mindset is the key aspect of being successful. Don’t focus on processes or tools. Focus on shaping your mindset to become a value-driven person. Some suggestions to benefit from User Stories:
Don’t define solutions to implement. Focus on the problem you want to solve.
Don’t overthink the details. Focus on the conversation with the team.
The solution is not for you; it’s for the end-user.
If you want to learn more about User Stories, I’ve got some more articles to recommend to you.
What are NOT User Stories?
The 4 most common misunderstandings of Users Stories that block Scrum Teams from thriving.medium.com
Improvement Stories: a simple alternative to User Stories
You are the Product Owner for a Scrum Team. Your team has just released a brilliant feature they have been working on…medium.com
It’s time to start writing useful User Stories!
Five simple tips for turning User Stories around from pointless to great!medium.com
Do you want to write for Serious Scrum or seriously discuss Scrum?