When we hear the word requirements, it sounds like a rule. It’s already defined what to do. We have little space to explore what’s the reason behind the requirements. Implementation is what matters the most.
A vital aspect of Users Stories is to wear the end-users’ shoes. We should be curious to understand the users’ perspective. We have to accept we don’t have all answers. We collaborate intensively until we clarify what matters the most.
You can identify User Stories representing requirements when Product Owners:
- Write detailed User Stories.
- Define all Acceptance Criteria alone.
- Invest significant time writing many User Stories.
Once Product Owners fall into such traps, the results are dreadful:
- Conversations to build shared understanding will barely happen.
- The focus is on implementing the requirement instead of clarifying the users’ needs.
- The Product Backlog contains hundreds of User Stories, which leads the Scrum Team to feel incapable of delivering on the expectations.
- Product Backlog Items last for years in the Product Backlog but are never implemented.
- Nobody dares to delete an old User Story because someone invested a significant amount of time writing it down.
A good User Story should represent a problem to solve, instead of a solution to deliver.
Some years ago, I used to think Product Owners are responsible for the why and the what. Therefore, I thoroughly planned the solution so that the Development Team could focus on the implementation. I thought I was optimizing our process. Actually, I was leading the team to a feature factory anti-pattern.
My misconception put a lot of pressure on myself and created multiple problems:
- I had no time to understand what problems were worth solving because I was too busy thinking about the solutions.
- The Development Team was disengaged because they were implementing solutions instead of solving problems.
- We couldn’t become a high-performing team because we lived in silos. Everyone had a specific responsibility instead of being a team.
“Your job isn’t to build more software faster: it’s to maximize the outcome and impact you get from what you choose to build.”
― Jeff Patton, User Story Mapping: Discover the Whole Story, Build the Right Product
It took me a long time to understand I was wrong. The Product Owner is responsible for identifying the relevant problems to solve, while the entire Scrum Team creates the solutions for the problems. If Product Owners craft the solutions alone, the Development Team will miss all the fun. Developers are creators; they love solving real problems. That’s what motivates them.
Users Stories focused on solutions will lead Scrum Teams to discuss the implementation. The Scrum Team explores how to deliver the solution while forgetting to understand the problem clearly. The result might be a solution that solves the wrong problem or no real problem at all.
When User Stories describe a real users’ problem, the Scrum Team engages in a deep conversation to precisely understand the problem. Once the team has built a shared understanding, they engage in crafting a meaningful solution for the problem.
“Fall In Love With the Problem, Not the Solution” — Kaaren Hanson, VP of Design Innovation, Intuit
Product Owner: Our team is overloaded. We will have to transfer some of our User Stories to another Scrum Team. Otherwise, we will not match our goals.
I’ve heard this request multiple times, and sometimes I was the one doing it. What was the result? Confusion. I was optimistic; I thought a handover to another team would be enough. But it wasn’t. User Stories are more than what it’s written on a card. They have a context behind it, which only the people involved in building the context understand precisely.
User Stories are not tasks to execute. For example, setting the backup for the application is a task. It is clear what to do. Therefore, it can be done by different teams. However, a User Story is more than words. Great User Stories carry a picture behind them, which only the people involved in the conversation can see.
If you look at a picture of your childhood, what do you see? You probably see more than a kid. The picture triggers your memory and brings a story you and the people in the picture can retell. But if I look at your picture, I will only see a kid. I cannot retell the story from the picture because I was not part of it. It’s precisely what happens with User Stories; only people involved in creating the story can retell it.
As pictures, Users Stories also represent thousands of words.
Every single Product Backlog Item should be written in the User Story format. That’s a myth. Scrum doesn’t define the format of the Product Backlog Items. The Scrum team can define what fits best.
Let’s have a look at what the Scrum Guide says about the Product Backlog.
The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
— The Scrum Guide, November 2017
Although User Stories work well in combination with Scrum, it’s not mandatory to use it. If we try to force everything into User Stories, it will be counterproductive. Imagine the following needs:
- Technical requirement: As the Development Team, we want to update our Angular version to have the newest components.
- Bugs: As a User, I want to ensure the Paypal payment works to pay my orders with Paypal.
- Technical Debt: As the Development Team, we want to refactor the invoice code to maintain it.
It’s a waste of time to write these tasks in the User Story format. Also, it brings no value during the refinement sessions. By forcing everything into User Stories, we miss the point of using User Stories. We should use User Stories when it makes sense.
If you find yourself forcing requirements into a ‘User Story’-template, consider what purpose the story serves. Is this the best way to make the Product Backlog understandable both to the Scrum Team and its stakeholders?