While working with Product Owners over the years I have learned some rules of thumb that make their Product Backlogs more manageable. Some of these items are what I have learned from others and some are just working with Product Owners though trial and error. Remember these are rules of thumb and help guide your management of a Product Backlog. They are not rules to adhere to no matter what. Always use common sense when applying a rule of thumb to your context.
The first one that I would like to discuss is the:
Keep your Product Backlog between 50 and 100 items total
This is difficult for some Product Owners at first. They may be collecting items from bug databases, issue tracking, stakeholder requests, and customers. A Product Owner may hear that this list must represent the prioritized list of work to be done on the product and then dump any item they can find into the list without making them easily consumable. Find ways to gather items into larger groupings and remove items that are not on your Product Roadmap yet.
The top 20-40 items are small enough to fit into a team’s Sprint
The top of your Product Backlog represents what is in highest priority to be implemented by the team. It is important to work with the team on making these items small enough for those items to fit into a Sprint. Getting estimates of cost from the team can help a Product Owner guage if the item is small enough to fit into a Sprint. If the item is important but sized too large to fit then the team can help the Product Owner break it down into smaller pieces.
Put acceptance criteria on top 20-40 items
Acceptance criteria could be a bulleted list of capabilities the Product Backlog item should put into the product once it has been implemented. These can be thought of as the functional acceptance tests for the Product Backlog item. If your list of acceptance criteria is getting larger than 7 bullet points then…
Break up Product Backlog items into multiple items when acceptance criteria is larger than 7 capabilities
Of course, there are also times where the Product Backlog item is too small and does not do enough on its own to create value for the product. In that case there is the following rule of thumb…
Each Product Backlog item should have at least 3 acceptance criteria about its implemented capabilities
Having too small of Product Backlog items is not always a bad thing but it could be difficult to manage and provide visibility into. I have found it also leads to Product Backlog items that are technical in nature without business benefit. As a Product Owner, it is usually difficult for me to guage the correct priority for something technical so…
Every Product Backlog item should present value that a Product Owner can understand and prioritize effectively
You may use abuse stories to help drive out the value to users for infrastructure or architecture Product Backlog items as written in this blog entry. However, a Product Owner could work closely with the team to delve into the value of their technical items through questions and learning. It is important that a Product Owner does not take the team’s technical items too lightly since those could be capabilities that allow your release to be successful. Such as scaling to meet your 100,000 users on the site at once.
The entire Product Backlog should be prioritized in stack rank order and…
The entire Product Backlog should be estimated by the team who is going to work off of it
These are the basics for Product Backlog management but I thought I should reiterate them. I often find that the Product Owner does not take time to prioritize their entire Product Backlog. The Product Backlog provides visibility to stakeholders, management, and the team about how the product is proposed to move forward. It is sometimes difficult to prioritize if the Product Owner does not have a cost to weigh against the benefit for each Product Backlog item. The team who is actually going to implement items off the Product Backlog should be the ones who estimate it as a group. Not any individual outside the group who will tell the team how long they should be taking on each item. From this costing of the Product Backlog it is possible to…
Generate a release burndown to monitor the release plan
Once you know how much the team can take on each Sprint you can do some ad-hoc release planning by going through your estimated Product Backlog and finding out how far they will be after n number of Sprints. Once you put this on a Release Burndown you can monitor that release and see if any changes must be made to the plan based on the reality of implementation or emergent requirements. You may even hold a Release Planning event with your entire team, stakeholders, and other interested parties to create a subset of your Product Backlog that is expected to be in the next release. With all of these parties coming together, a Product Owner may get more items to put into their Product Backlog where gaps were found by the team and stakeholders.
This listing of some Product Backlog rules of thumb is just a start. I have found it helpful to go through this list with new or troubled Product Owners. Please let me know if you have any other items for the list or if you disagree with some. I am always interested in what others have found helpful.