Product Backlog Rules of Thumb
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 item into multiple items partitioned by common functionality within the original item.
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
Having Product Backlog items that are too small 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 direct business benefit. The Product Owner could find it difficult to gauge the correct priority for an item that is too technical so...
Every Product Backlog item should present value that a Product Owner can understand and prioritize effectively
Abuse Stories can be used to drive out the value to users for technical infrastructure or architecture Product Backlog items. An Abuse Story identifies the cost of not addressing a technical aspect of the product. For instance, in the case of fraud, an Abuse Story such as the following could be identified as a Product Backlog item:
As a Malicious Hacker I want to gain access to credit card information so that I can make fraudulent charges
The acceptance criteria for this Product Backlog item would be the technical modifications that will be made to stop the Malicious Hacker from gaining access to credit card information. The risk identified in this Product Backlog item helps the Product Owner better prioritize beside other potential candidates for upcoming Sprints.
The entire Product Backlog should be prioritized in stack rank order
And...
The development team that is going to implement the product should estimate all Product Backlog items
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. If kept to a manageable size, the Product Backlog provides visibility to stakeholders, management, and the development team about what is coming in the near future. It is 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 only people who estimate the items. No individual outside the group should tell the team what the estimates are. After the Product Backlog is fully estimated, the Product Owner should...
Generate a release burndown chart to monitor progress toward a release of the product.
Once you know how much the team can deliver each Sprint (velocity), 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. This ad-hoc plan can be monitored on a release burndown chart to see if any changes must be made based on the reality of current implementation or emergent requirements.
This listing of Product Backlog rules of thumb is just a start. I have found it helpful to go through this list with new Product Owners or Product Owners finding it difficult to manage their Product Backlog. As a Product Owner becomes more proficient in their Product Backlog management technique then they can step away from some of these rules of thumb to optimize for their environment.
About the Author
Chris Sterling is an Agile Coach, Certified Scrum Trainer, and Technology Consultant for SolutionsIQ. He has been involved in many diverse projects and organizations and has extensive experience with bleeding edge and established technology solutions. He has been a coordinator of multiple Puget Sound area groups including International Association of Software Architects (IASA), Seattle Scrum Users Group, and most recently the Beyond Agile group. He has been a speaker at many conferences and group meetings including Agile 2007 amp; 2008, SD West, Scrum Gathering, and others. In his consulting and speaking engagements, Chris brings his real world experience and deep passion for software development enabling others to grasp the points and take away something of value. Chris has also contributed to and created multiple open source projects. He is currently teaching the “Advanced Topics in Agile Software Development” class at the University of Washington Agile Developer Certificate extension program and writing a book with publisher Addison-Wesley on software architecture.
