25 March 2013
No prioritization
Although there is a product backlog that contains almost all the work that can be planned, there is no real prioritization and things get picked up ad hoc, purely based on reactionary prioritization. In most cases this is a symptom of a number of possible underlying diseases. More often than we like to, we see product owners not really equipped for reaching their maximum potential of optimizing the value created for the customer. The most typical reasons for this are a limited toolbox of techniques and lack of time. The latter might be the case simply because the product owner role is not the only role this person is trying to fulfill.
Work items not being described as problems but as solutions
It is the team’s responsibility and expertise to come up with solutions to the problems that stakeholders are throwing at them. When you come with a solution to a team, you disregard the experience and knowledge of the team members and you will most probably not end up with the best possible solution for the problem the stakeholder is really struggling with. That’s easy because the team doesn’t even know what the real problem behind this solution is, so they can’t use their own professional creativity to help come up with an alternative solution. This is why we stay in the problem domain as long as possible, only going down into the solution domain when we are almost ready to start developing the solution. At that point, the solution will be co-created by the team and the product owner, possibly together with the stakeholder who stated the problem in the first place.
Splitting off too many stories up front
When the product owner starts grooming the backlog and splitting off smaller stories from epics and capabilities, he sometimes gets a bit too carried away and goes too far. As a product owner, it is your responsibility to prepare detailed stories for the upcoming sprint with a margin of about half a sprint. If you have more detailed stories in there than the capacity of the team suggests, you have invested time and energy in preparing too much. You are not only disregarding the possibility of change on the horizon, but also the learning you will get by finishing the current sprint. You are also spending more time on this than necessary, which may lead to you not having enough time to support the team with impediments and questions about the stories.
Adding too much detail on user stories
The whole concept of a user story is based around the fact that it is a conversation starter. Whenever team members get the feeling that all the needed information is on that index card, they will just go ahead with what is written there. And if there is anything we have learned by writing detailed requirements documents over the last few decades, it is that no matter how much time and energy you invest in them, they are never complete. This is why it is important to always leave some information off the index cards, to help people start that conversation when they pick up the work during the sprint.
