Sustain Product Backlog
The Product Backlog is the vehicle by which needs are turned into requirements and requirements are turned into operational features in our product. It is a prioritised list of the work that the team currently intends to deliver in the next period of time. The less imminent a feature is, the less well it will be defined.
In A Nutshell
The Product Backlog is an evolving picture of the work that teams will be performing in the short-term. Its content is aligned to the most immediate time horizon defined in the Product Roadmap to prevent excessive dwell time of backlog items. If priorities in the roadmap change then backlog items will need to be pruned and new backlog items added to ensure continued alignment.
When backlog items are added to the backlog they typically give a high-level, abstract view of the feature. This view needs to be refined so that, by the time the team starts work on the item, it has sufficient detail to facilitate the work. Refining the backlog item in this way helps the team to establish a common understanding of the requirement and the work needed to implement it.
As backlog items are refined the additional information may show that the item is too large to be worked effectively by the team. Backlog items are decomposed to form smaller, more manageable backlog items. The process continues until the team decides the items are right-sized and sufficiently detailed to be implemented successfully.
The Scrum activity of Product Backlog Refinement implements this practice.
Related Practices
Product Backlog Refinement is a Scrum activity that is performed on the Product Backlog. The scrum guide defines Product Backlog Refinement as the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
Related Articles
Relative estimation is a simple concept, but one that causes all sorts of problems for new teams and for experienced agile practitioners. This article examines some of the reasons behind the confusion and suggests a new, clearer way of thinking about the process of relative estimation. This new pattern makes a very clear break from more traditional estimating techniques.