When I coach teams and their product owners, one of the first areas I want to help them correct is the backlog refinement sessions. Most of the time these are hours-long grueling meetings where the teams are wondering, “Why can’t we just go code?” Just like many things, the pain that people feel in a new process is because of inefficiencies upstream. In this case, the product owners often have no idea how to present the information to the team to be able to size, refine, split, and ultimately deliver the story. In this article, I will explain “How to Explain and Present User Stories.”
Step 1: Present the background and business case
A big mistake I see product owners make, especially with new teams, is to jump directly into reading the story to the team without giving background. In the case of a project that already has some momentum, this us understandable. You certainly don’t want to reinvent the wheel. However, for teams that are starting out a new project, it is very important that you present the background and business case associated with this project.
Step 2: Present the problem and feature area
Problems that are big enough, complex enough, and important enough to require a software team generally have “sub problems” associated with them. These sub problems have feature areas to solve for them. The sub problem and feature area are important because its another step down in granularity. This gives additional context to the conversation.
Step 3: Present the user story and acceptance criteria
Now is the time to present the user story, which is fine, because the team has mental boxes to put it into:
- What is the big picture problem we are trying to solve
- How have we decomposed that problem into smaller problems
- What is the specific small problem we are trying to solve with this user story in particular
As you present the user stories, you will also need to present the acceptance criteria for the story. Invariably, the team will have questions about the acceptance criteria, specific use cases, and other scenarios not outlined in the user story. Make sure you (or your Scrum Master) update the story with this additional information. The conversation is the most important part of a user story.
Step 4: Ask the team if they have enough information about this user story to size it
The first couple times, the team will be taken aback at the directness of this question. But this question is very important to the progress of the meeting. As new stories and requirements are presented, sometimes the conversation degrades into an architecture discussion, or a trip down memory lane reminiscing about the last time they developed a similar feature. This is fine, but left unchecked, the conversation will go on forever. So you will need to ask the team every so often “Do you have enough information about this user story to size it?” If they don’t, your next question should be “What else do you need to know about this user story to be able to size it?” Continue to ask this until you get a reasonable size.
The big picture
As I always like to say, “Context is everything.” The difference between how I suggest product owners present user stories and how its done in real life is that my method gives full context. If we want to leverage the collective brainpower of the team, everyone needs to understand what kinds of problems we are looking to solve, for whom, and what is the business impact. That will enable us to make smart decisions and tradeoffs when it comes to delivery.