Overview
In the Ever met a good product owner post, we ran through some of the responsibilities of what will help to make a “good” product owner.
In this post I cover three common problems with the backlog that Bob the product owner may have.
The backlog is too thin
It is sprint planning day. The team walks into the room, and Bob starts asking the team for any stories that surfaced last sprint. After about 10 minutes, as Bob keeps fishing from the team, it suddenly becomes clear that there is no backlog, and he is trying to come up with stories on the spot.
Under more healthy circumstances, Bob should be juggling with more stories than what the team can handle.
Symptoms
Bob could be struggling with a lack of vision; he doesn’t know where to start, or what needs to be done to provide value. This could be because there is not enough collaboration happening with key stakeholders, or customers, or validation against the current market.
Bob could have the opposite problem; he doesn’t know where to start because his vision is so vast.
This could also signal a wider problem in the business, that there is a gap between them and the team, and that it is not clear on how the agile process works. Usually an organisation is packed with domain experts sitting right there a stones throw away; account managers who know exactly what the customers are screaming for, sales people who know a killer feature that could squash the competition, administration staff that have an idea that could slash costs in half. There will be many ideas out there, but the experts have to know how, and who to present them to.
Fix it!
A backlog should always be at least a sprint of work ahead, so it should be very clear early on that this problem is developing. Approach the product owner with a view to help.
The easiest place to start maybe to collaborate with the key stakeholders and experts in the company, as they should be more easily available.
Next, the product owner may need to go to a wider group of stakeholders or analyse the market to help decide on what is valuable. A great resource to help here is the Lean Startup, particularly where it talks about Actionable Metrics.
Once a vision or goal is determined, it needs to be translated into features and user stories. A great model that specialises with this is Impact Mapping. Other requirements gathering techniques such as wireframing and story boarding can help flesh the stories out.
The product owner may need some support here. While they should be driving the process, agile coaches and scrum masters can certainly provide some support here with training and facilitation. They can also educate the business on the teams agile process, and importantly the correct channel on how to propose features that they think will be valuable.
Remind the product owner that through all of this, their story selection doesn’t have to be the perfect high value, small sized stories right off the bat. Even at the most informed of times, there will always be an element of uncertainty. That is the beauty of empiricism; we pick the stories that we think are the best ones at the time, then inspect, adapt and improve.
The backlog is too big
It is sprint planning day, and Bob walks in with his laptop. He has 647 user stories in a Jira board and picks the top 20 to go through with the team.
Why is this a problem? If a new feature comes in, Bob now has to prioritise it against 647 user stories. A near impossible feat; there is a good chance that this feature will sit in a back log and not be done for months, if ever. This is hardly agile!
The 647 user stories represent say 30 sprints of work. This means that the product owner has put effort into writing and cataloguing a huge number of stories that will not be looked at for a year. By the time the team is ready to pick up these stories, things will have changed. Perhaps it is no longer needed, the client that asked for it has left. So older stories then have to be continually re-evaluated. Planning stories too far advance is a lot closer to being up front and predictive than agile and results in large amounts of waste.
Prefer responding to change over following a plan - Agile Manifesto
Oh yeah, and a plan that far in advance goes against that too.
Symptom
Quite obviously, the product owner isn’t saying “no”. Although such a small word, it can be much harder to say than you think.
When an account manager is begging for a feature or their client will leave, a sales director is yelling down the phone that a feature has to be done because “he has already sold it”, when the CEO takes Bob out for coffee and says he wants something done, little Bob feels pressure.
It may also be a symptom that Bob has not been empowered enough to truly manage the product backlog himself. Maybe he can’t say no. Managers above him constantly trump him.
Fix it!
Again Bob needs support here. He needs to be empowered enough to truly manage the backlog himself. After all, he is the one who has been tasked with being responsible for the product on behalf of the whole company. Agile coaches, scrum masters, you may need to educate to make this clear.
Secondly, Bob might need training on how to manage expectations. When he gets a new feature request, and he has evaluated that it is not high enough priority to be done soon, he needs to say no. This might really annoy the business at first, however that is much better than saying yes, and then it going into an “IT black hole”. Transparency might hurt in the short term but it is always better in the long run.
Finally, another quote from the agile manifesto:
Prefer individuals and interactions over processes and tools
How does a backlog get to 647 items in the first place? Because use of a tool allowed it.
Now imagine if instead of using a tool like Jira or Trello or TFS or Excel or anything else, Bob used just a simple paper card and a felt tip pen to write down the user stories. Would he ever let the number of stories get to 647? The stories would cover the hallways! (Admittedly, I have seen this before, but don’t let that detract from this point).
There will be many reasons to stick to using a tool. “We have to tie them with defects”, “We need to keep track of progress”, “I am a Jira admin and would be without a job if you didn’t use it”. I always encourage use of physical cards, and only resort to using a tool at the point that it becomes absolutely necessary, like for a team that might work remotely. Physical cards help to keep stories well sized, limit how many can be managed at once, and more importantly should be an invitation for a conversation. They cannot contain essays of annotations or wireframe attachments, good - let’s have an interaction instead and get that detail from the horses mouth.
The user stories are too big
That’s a thing you ask? Think about it this way - a sprint, or an iteration, is like a game of Tetris. The Tetris board represents the limited time that a team will have, and the pieces can represent the user stories. Imagine if in a game of Tetris, all of the blocks that fell from the top were just 1 block pieces. The game would be too easy; filling the board up efficiently with little waste would be a breeze. But as the Tetris blocks get bigger - say they start coming out as 10 block pieces, well filling the board efficiently becomes challenging if not impossible.
It is the same with user stories. Nice small stories that can be done in a day or two are great for the team to work efficiently on, and plan for. As the stories get larger though, and they start taking multiple days or even weeks, well this makes it almost impossible to plan for. Certain people get stuck on the story, it becomes difficult to test, changes may start overlapping and impacting other stories, the list goes on.
Symptoms
Simple really: the team is missing an important meeting called refinement. It is natural that the product owner will get feature requests as epics, or “very large stories”. But these large, “coarse grained” stories need to be refined so that they are ready for the team to work on.
The product owner and team may also not be familiar with how to write good user stories; it is something that takes a bit of training and practise.
Fix it!
As these large, coarse grained stories stories move closer to the top of the backlog, and closer to being worked on, some work needs to be done on them. The stories will need to be broken into smaller stories, have acceptance criteria added to them, be sized, and prioritised. This type of work is typically done with the team in refinement sessions so the backlog is nice and ready for sprint planning.
The product owner, and the team, may also need some coaching on how to write good stories that abide by the INVEST principles. More to come on this later.
Summary
There are a number of different problems that product owners may have with the backlog; this post has run through only a few of them. No one ever said the job is easy! But with a bit of training, and the right level of support from the team, the agile coaches and scrum masters, we can always try to move towards having a healthier backlog for the team.