Recently I facilitated a workshop between multiple Scrum teams in which we discussed the area of backlog management. The main purpose was to gather some best practices for managing the product backlog. With this blog post I will share the outcome of the session, hopefully they are useful to you, otherwise I gladly receive other best practices you might know.
1. Managing the Product Backlog should always be done with a clear vision of the product on top of mind. Changes to the backlog should always correspond with the product vision. Roman Pichler created some very useful templates to define a product vision.
2. Order the Product Backlog based on priority, value, dependencies, risk and how much you will learn. Often only priority and value are considered. But, for example, although the roof of a house might be the most important in a rainy area, you still first need to build the foundation. Therefore, when ordering a backlog, also take into account the dependencies, risk and amount of learning.
3. Consider managing the Product Backlog as an effort for the entire team. Although the Product Owner is responsible to order the backlog, it’s up to the complete team to provide all the necessary input. Writing user stories therefore is also a responsibility for every team member. The Product Owner can define the stories, but it’s up to the team to make them ‘ready’.
4. Make sure the Product Backlog is easy to approach for every team member. This may sound obvious, but too often I’ve seen the backlog stored on the local machine of the Product Owner. Afraid the team might add some changes without him/her knowing about it. This approach does more harm than good and inflicts a lack of transparency, trust and collaboration between the Product Owner and the other team members.
5. Share the Product Backlog with the stakeholders. Don’t hide the backlog deeply in some complicated tool, but make it transparent to the stakeholders so they can continuously check the last status and provide feedback. Eventually this will support building the foundation of trust that’s necessary when e.g. difficult decisions have to be made.
6. Keep the Product Backlog manageable. It might be tempting to continuously add new stories to the backlog so you don’t have to say ‘no’ to stakeholders. But it’s very time consuming to keep the backlog up-to-date. And otherwise, it’s also not fair saying “sure, I’ll add it to the backlog”, but thinking, “we’re definitely not going to build it the upcoming time”.
7. When using a tool, ensure it supports you in using the Product Backlog. If too many undesired constraints are necessary, try another tool or better: don’t use one at all. Too often I see teams getting stuck in the workflow the tool dictates, if this happens: get rid of it!
8. Use the DEEP (detailed, emergent, estimated, prioritized) acronym as a guidance for managing the Product Backlog and INVEST (independent, negotiable, valuable, estimable, small, testable) as a checklist to ensure high quality user stories.
9. Use the Backlog Prioritisation Quadrant to make all the different parts of the Product Backlog transparent and use it to order and balance the backlog properly.
10. Ensure there are always at least two sprints of Product Backlog Items ‘ready for sprint’ (clear, feasible, testable). To use Pacman as an example: when he can’t ‘eat’ enough PBI’s anymore because they aren’t small enough, backlog refinement is necessary.
These are just some of the tips & tricks that came up during the workshop about backlog management. If you know any others, feel free to share them!