Not covering some essential details when you present user stories to developers can affect the sprint. When these details are overlooked, developers don’t entirely understand from the beginning what they have to build.
They start the development of a feature, then you have to change the description and acceptance criteria later on when they notice the missing information. The consequences of doing this are not to be left unnoticed.
You will end up in a place where you either have to give up something else in the sprint in order to complete that story, or you will carry it with you into the next sprints.
I have found myself in this situation many times. But with time I identified different approaches I can take.
If you have never analyzed what is the first thing you do when you open a user story, I recommend you do it next time. Then pay attention to what your team’s reaction is and what is ambiguous to them.
I have prepared a list of 4 common mistakes that Product Owners make when talking about their stories. So, if you find yourself in a situation where you don’t know what is not working in your team, read below.
Mistake 1. Not sharing the business case with the team
Developers can develop features best when they have a goal in mind. And that’s because it allows them to quickly identify edge cases and isolated scenarios while writing the code.
What happens when the only thing you know is just around the feature you are going to implement? You lose sight of the bigger picture.
It’s important for developers to know what business problem they will solve. And why they need to solve it. This way, while you present the user story, they can many times identify other adjacent stories that you need.
They are aware of technical debt going around and can point out what areas would need refactoring before developing a new feature in those areas.
The business case should be presented only when you work on some new feature. You don’t have to bring it up in every refinement.
Mistake 2. The context of the user story is not discussed in Refinement
Why you should never ignore the context of the story you present?
- You limit the creativity of your team
- It’s more difficult to develop a functionality when you don’t know how it integrates with the existing functionality
- You might miss the chance to get help in finding gaps between user stories
- Developers must be able to negotiate the sprint goal whenever needed
Limiting your team’s creativity has an enormous impact on their motivation. And you can notice a significant difference between a team that is specifically told what to do and one that is allowed to be innovative.
Also with more minds thinking of a solution, the chances to identify all the steps and eliminate the risk of leaving out certain elements is much higher.
One other thing that knowing the context allows developers to do, is negotiate the sprint goal when things get out of hand. Negotiation is a very useful tool.
It happens many times while working on a user story. The team realizes things are more complicated than they thought initially. Which sometimes would cause them to cannot complete the user story in a sprint.
But knowing the context, they can come up with solutions to implement the functionality differently, while still delivering what was required.
So making the context known brings benefits to both Product Owners and Developers.
Mistake 3. Acceptance criteria not written collaboratively
Why should acceptance criteria be a joint effort between the Product Owner and Developers?
- It helps the team understand the desired feature
- It helps the Product Owner catch missing information
The Product Owner writes the acceptance criteria before discussing the user story with the team. However, it is not only their responsibility.
The development can and should contribute to writing acceptance criteria together with the Product Owner.
Yes, it might take longer to complete the discussion about one user story. And yes, in this case, you might not discuss as many user stories as you do when you don’t collaborate with the developers.
But the knowledge the team will gain from this exercise and the missing details you’ll identify save you from requesting changes after development starts.
Mistake 4. Leaving the meeting without clarifying the team’s questions
There are several ways to answer the questions that the team has regarding the user stories you present.
- In the Refinement session in which the user story is discussed
Clarifying the user stories is necessary in order for your team to estimate it.
Developers need to understand precisely what the requirement is, and the areas in which they will work. Otherwise, it will become challenging to have an accurate estimate. User stories should not be accepted into the sprint without a clear description and acceptance criteria.
When it happens, there’s a high chance to have to increase the effort and complexity for the working item, during the sprint.
- As soon as possible after Refinement
If the user story is still not clear after Refinement and must be included in the next sprint, you should revisit it before the Sprint Planning.
In case there are too many stories in this situation, I recommend not waiting until Sprint Planning to discuss the additional details. You don’t want to refine user stories in your planning session.
You can ask the Scrum Master to help you set up a meeting with the team so that you can resume the user story from where you left off.
However, if what you need to clarify for a particular user story is not something too complex, it is acceptable to talk about it during planning.
- In the next Refinement session
Ideally, you are refining stories for one or two sprints in advance. So if the working item falls into this category, you can reopen the discussion in the following Refinement.
Final thoughts
Discussing a user story is more than opening the working item and reading a brief description. It’s like telling a story.
When you tell a story you always start with the begging. It shouldn’t be too different when you present user stories either.