Next up in my blog series on “Anti-patterns that Doom Product Owner to Fail” is the topic of product backlog management. The Product Owner is responsible for the Product Backlog, and if it’s not well cared for, the team could work on things that don’t provide any value. Now, let’s look at some of these anti-patterns:
Not doing backlog refinement with the Scrum Team
Problem
The Product Owner should not work on the Product Backlog in a silo. Product Owners who try to “go it alone” will soon discover that their team doesn’t have the necessary context to size and deliver the work in the backlog.
Solution
The Product Backlog is the source of all work for the Scrum Team, and it needs to be regularly revisited and refined with the team. By having backlog refinement with the team, the Developers can ask questions, clarify issues, and size the User Stories.
Inability to prioritize
Problem
Another problem I have seen with Product Owners and the backlog is when the PO can’t prioritize. Prioritization is challenging because it involves considering many different aspects: value, size, dependencies, complexity, etc. And to top that all off, if you try to stack rank an entire Product Backlog log in priority order, you’ll drive yourself crazy.
Solution
I often borrow the quote from the movie Highlander, which states that “there can be only one.” Only one item can be the #1 priority. After that, it’s a matter of choosing the next highest priority, and so forth. I would recommend only ordering the top 10-20 items in the Product Backlog because anything after that will be less detailed and probably not right-sized to develop.
The Product Owner doesn’t protect the Product Backlog
Problem
Again, the Product Owner is responsible for the Product Backlog. But this doesn’t mean the PO must do all the work managing the backlog by him/herself. Other team members can contribute to the backlog, but they may only do with the PO’s knowledge and consent. And even then, there is no guarantee that the backlog items will be developed.
Solution
The Product Owner should always be aware of the contents of the Product Backlog. When you add something new to the Product Backlog, you must inform the Product Owner. It’s then up to the Product Owner to decide when (or if) the requested item will be prioritized for development. TIP: Remember that everything in the backlog should be negotiable (think INVEST).
The Product Backlog a is considered a commitment
Problem
The Product Backlog is not like the colossal Software Specification documents of the past. Nor is the backlog a promise that everything in it will be built. Unfortunately, stakeholders think that because it’s in the backlog, it will get done. This isn’t true.
Solution
There’s no promise or guarantee that the Product Owner will prioritize your Product Backlog items. The Product Owner must communicate this message to any contributors to the Product Backlog, whether it’s a team member or a stakeholder. Remember, a User Story is a promise to have a conversation, not a commitment.
There aren’t enough “ready” stories to feed the team
Problem
It’s time for Sprint Planning, but there is nothing “ready” for the team to pull into the next Sprint. The Product Owner has neglected the Product Backlog and failed to stay one to two iterations ahead of the Scrum Team. When this happens, the team might want to start working on things that aren’t suitable for development. Unfortunately, this will cause back-and-forth questions and slow the work down significantly, which is the opposite of what it means to be Agile.
Solution
Ensure your Product Backlog has enough “ready” User Stories for the Scrum Team before each Sprint Planning meeting. Have regular backlog refinement sessions with the team throughout the Sprint for upcoming Sprints, so when you go into planning, your team isn’t seeing the items for the first time; this will also speed up your planning sessions.
Final Thoughts
Managing the Product Backlog is a big job, but the Product Owner doesn’t have to do it alone. Anyone from the Scrum Team may contribute, but it is still the PO’s responsibility to ensure that the highest value items are prioritized. The PO must also take care that there are Product Backlog items ready for development when it’s time for Sprint Planning.
Now, it’s your turn. What problems have you seen crop up when it comes to the management of your Product Backlog? Please let me know in the comments below!