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
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