While working with Product Owners over the years I have learned some rules of thumb that help make their Product Backlogs more manageable. Some of these rules of thumb I learned from other people and some were learned through trial and error.
Remember that the statements contained in this article are just rules of thumb intended to 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 particular context.
The first rule of thumb that I would like to discuss is the:
Keep your Product Backlog between 50 and 100 items total
It is common for a team or organization to implement Scrum and find their Product Owner overwhelmed by the mass of the Product Backlog. The Product Backlog is filled with every feature request, suggestion, defect and infrastructure improvement. The Product Owner is no longer able to effectively manage the Product Backlog and maximize the value of delivery through prioritization.
To combat this unmanageable mess, gather related Product Backlog items into a single, larger Product Backlog item so they can be managed as a group. As these combined Product Backlog items get higher in priority they can be easily expanded into their smaller, contained items and prioritized individually among a smaller subset of high priority items.
Also, go through the Product Backlog and remove items that are not directly aligned to the product roadmap. Frequently, items are kept in a Product Backlog because they sound like a good idea but are not aligned with the overall product strategy. Figure out if these items should be represented on the product roadmap or are they a distraction from the product goals.
Next, lets make sure the Product Backlog is ready to conduct effective Sprint planning with by making sure...
The top 20 to 40 items are small enough to fit into the development team's Sprint
The top of your Product Backlog represents the highest priority items to be implemented by the development team. It is important to work with the team on making these items small enough to fit into an upcoming Sprint. Identifying the appropriate size of the top 20 to 40 items involves getting estimates of cost from the team. From these estimates, the Product Owner can gauge the appropriate size of items to fit into a Sprint. If the Product Owner believes a Product Backlog item is important but sized too large to fit into a Sprint then the team can help the Product Owner split it up into smaller chunks or simplify the implementation.
An appropriate size could be described by the following formula...
The upcoming Sprint should fit at least 4 of the highest priority Product Backlog items
After a team has executed 1 or more Sprints they can calculate their velocity based on data from those Sprints. Velocity is the amount of Product Backlog delivered within a single Sprint. Calculating the velocity is a function of Sprint duration, team makeup, sizing nomenclature, and product technology. Therefore if any part of that function changes then the velocity is no longer valid. The best way to get predictability in team delivery is...
Keep the development team together working on the product with a continuous Sprint cadence
The rhythm created with each Sprint having the same duration will help the development team understand how much they can commit to in planning and deliver successfully as potentially shippable code by the review meeting.
Have a description of the Product Backlog item is usually not enough to make it clear for estimating by the development team. It is helpful to...
Put acceptance criteria on top 20-40 items
Acceptance criteria could be a bulleted list of capabilities the software should exhibit once the Product Backlog item has been implemented. These can be thought of as the functional acceptance tests for the Product Backlog item. The development could also identify technical aspects of the functionality as acceptance criteria with acknowledgment of the Product Owner.
If your list of acceptance criteria is getting larger than 7 then...
Break up the Product Backlog