Product Backlog Contents

Product backlog items can be functional requirements, non-functional requirements, bugs and issues. The precision of the estimate depends on the priority and granularity of the Product Backlog item, with the higher priority items that are likely to be delivered within a few Sprints being more granular and precise.

Any idea or requirement can be added to the Product Backlog - from the most grandiose feature request, to the smallest non-functional requirement. This makes the Product Backlog a very useful tool for calming business users; some business users can cause friction in meetings by demanding or championing new features - in traditional projects this can cause conflict because the Project Manager is trying to keep a handle on Scope, where as in Scrum the answer becomes "Great idea, we'll put it on the Product Backlog and prioritise against the rest of the Backlog". This technique allows the "Novelty value" of the hot new feature to dissipate so that a considered, rational business priority can be applied.

Summary:

• List of features, often in User Story format
• Non functional requirements, e.g. performance and reliability goals for the new system
• Bugs and changes need to be visible in backlog so that they can be prioritised along with new features
• Issues are placeholders that are later defined as work
• The Product Backlog is emergent, prioritised and estimated
• Higher priority backlog items should be more granular and have greater precision estimates (although still high level)
• One backlog for multiple teams if they are all building the same system
• The Product Owner is responsible for setting the business priority
• Anyone can contribute backlog items
• Maintained and posted visibly
• Derived from the Business Plan, Vision Statement and any existing requirement documents which sometimes have to be created