The Scrum Guide – 2020
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.
Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is 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.
The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.
Commitment: Product Goal
The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfil the Product Goal.
“A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.“
The Product Goal is the long-term objective for the Scrum Team. They must fulfil (or abandon) one objective before taking on the next.
© 2020 Ken Schwaber and Jeff Sutherland
Commentary
Let’s take a closer look!
The Product Backlog is an emergent, ordered list of what is needed to improve the product.
“What is needed” covers everything. Thus – even though Scrum is typically used by software and system development teams – not only software needs. Even in software development, a need can be something radically different, e.g. a successful audit.
It is the single source of work undertaken by the Scrum Team.
In principle whatever the Scrum Teameam is working on, should be added to the backlog. Changes to already delivered features should also be represented by new backlog items. Personal ideas of senior managers should also be represented by backlog items – if the Product Owner accepts them. It should never happen that people are working on tasks without prior planning and without negotiating the item with the Product Owner. Transparency is a pillar of Scrum.
The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfil the Product Goal.
This paragraph may sound threatening to people accustomed to signed-off upfront documentation. However, it is uncommon to see a traditional waterfall-ish project going end to end without change requests and the fine-tuning of accepted requirements. Large organizations unfortunately have a tendency to choose a ‘fragile’ Scrum implementation. They feel safer with a signed-off, ‘sealed’ backlog and discouraging changes with an elaborate change process.
Practical Implementation
As per its content, the Product Backlog represents (but is not identical to) the business and delivery documentation of the product. The Guide does not prescribe any method regarding how to implement it. For instance, even a spreadsheet with an ordered list of high-level goals could be one – rudimentary – example of a Product Backlog. (Whether we can guarantee the transparency of this solution is a different question.) The most popular format is a Kanban-style wall or board with cards, i.e. the Scrum board. In this case, the physical position of the card represents its order – which is quite simple to change. There are many web-based agile tools with sophisticated backlog management functionality.
What happens when multiple teams work on the same product?
This question has the answer in the Scrum Team chapter:
If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.
The Scrum Guide – 2020
Tip: this is a typical exam question. While Scrum Teams can generally choose what works best for them, this statement has a place in the Scrum guide. The backlog of a single product cannot efficiently evolve in 2 separate instances. There would be no opportunity to use synergies if backlog items destined for different teams grow independently. The Nexus Guide further elaborates on the idea of scaling Scrum.
Product Backlog items that can be completed by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is 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.
Refinement
Backlog Refinement is the activity of uplifting Product Backlog items. Refinement was not a part of Scrum in the early ages. It was first introduced as ‘grooming’ in 2011, an unfortunate terminus due to negative connotations. The Guide does not describe refinement as an event, but rather as an ongoing process. In practice, backlog refinement requires a structured approach, e.g.:
- Writing/uplifting product backlog items is the accountability of the Product Owner. However, the Product Owner may delegate the corresponding tasks. As a thumb rule, we usually identify product needs (a.k.a. requirements) with business analysis. It is conducted with various techniques involving business and technical stakeholder workshops, research, etc. However, in Scrum, it is ideally part of product management, as detailed in the Evidence Base Management Guide.
- Estimating or sizing the backlog items is the responsibility of the Developers. Scrum Teams typically perform this in an organized manner, e.g. on a ‘story-time’ session, using planning poker or a different method. The Product Owner can negotiate different alternatives with the Developers to find a solution that has a smaller size yet delivers great business value.
- Ordering the backlog is the Product Owner’s responsibility, however, the estimation can be an important factor in deciding about the order. Stakeholder input is also vital.
- A team can establish a definition of “Ready”, paraphrasing the definition of done, to standardize what requirements should a backlog item meet to be sprint-ready.
The Guide gives a nice description of applying different planning horizons. Backlog items on the top of the list should be detailed, and ready for implementation. Backlog items at the bottom of the list can remain vague ideas and gain their shape later, based on more and fresher facts. This gives agility for an organization and a huge efficiency boost compared to the old-school way of creating comprehensive upfront documentation.
It is important to keep in mind that the Sprint Review can also have a significant impact on the Product Backlog.
Teams typically organize events for refinements, however, one-on-one meetings also take place. There are no common formalities, every team chooses their own practice. The refinement usually requires cooperation between the Developers and the Product Owner. A typical event held with this purpose is the story-time. This event serves to introduce new stories to the development team. It is very likely that the Product Owner (or another team member e.g. a business analyst) closely collaborates with other stakeholders as well, however, Scrum does not elaborate on this activity.
Estimating Product Backlog Items
There are various estimation techniques (agile or traditional) available. In an agile process, only the Developers can provide effort estimation. Logically, those who are implementing the items can estimate them responsibly.
The most popular technique in agile is the Fibonacci series estimation. This is a rough, ‘order of magnitude’ guess. The main point is that we can estimate small items relatively accurately, large items, on the other hand, have a much bigger uncertainty. Therefore the estimation is always a Fibonacci number: there are bigger gaps between bigger numbers. There are further similar approaches, e.g. using the powers of 2, or T-shirt sizes. The unit of the estimation is typically not a unit of time, but rather a comparable task, and usually named as story points. Thus, a very easy story has probably 1 story point and more difficult ones take further numbers of the series.
To improve the accuracy of the estimation, teams may use further collaborative techniques, such as the Planning Poker. The idea of Planning Poker is that every team member gives an independent (unbiased, unanchored) estimation. If the revealed numbers show huge differences, the item deserves further investigation. If the numbers are close to each other, their average will suffice.
Monitoring Progress
The current version of the Guide does not recommend specific tools anymore, what is more, it does not mention this at all. There are a number of good solutions for monitoring progress, therefore the Guide rightfully leaves room for choice.
The popular way of monitoring the progress is a combination of the following:
- Measuring velocity: That is to say, calculating the ‘average delivered value’ for each Sprint, e.g. based on ‘story points’, effort estimation, number of delivered backlog items, etc. Story points are a great help in iteration planning. The number of delivered story points per sprint is typical to a team and more-or-less similar across iterations. Therefore the story points are great indicators of whether a Sprint has too many Product backlog items.. Velocity gives an idea of how much time the Scrum Team needs to process a given amount of product backlog items. Also, to some extent, it is an indication of whether the team is improving. However, we cannot compare the velocity of different teams to each other.
- Declaring a Minimum Viable Product or another milestone: the Product Backlog, as a living artifact, can be in constant growth, giving the impression that there is no progress toward a goal. Declaring a more-or-less fixed scope goal helps to compare the current status and the goal.
- Maintaining a product burnup chart: The burnup chart visualizes the change of delivered product backlog items over time and the difference between the remaining and delivered items. The same unit of measurement should measure velocity.
FAQ
No. Even though Scrum practitioners often use ‘user story’ when they talk about a Product Backlog Item, they are quite not the same, see the table below.
No, it definitely has practical consequences. This differentiation opens up opportunities in defining, managing, structuring, capturing and constructing our product documentation, list of ideas, features and needs, etc. While it is possible to capture (almost) every Product Backlog item with a user story, even physically on a paper card that represents the Product Backlog item, we can choose other solutions, too.
For example, the Product Owner can maintain a single concise document that supports not only development but also describes the product for future users, too. In this case, Product Backlog items only refer to the separately maintained product description. Let’s see this with an example. JIRA is a popular issue tracker with a Scrum Board which is capable of capturing all needs in the ‘body’ of a backlog item. However, many teams opt to maintain their business needs and product solution description in Confluence (a document management tool from the same vendor) and interlink the documentation and the Product Backlog Items.
If no practices support establishing estimation and value, all Product Backlog items will have the same estimation and value. This makes the Product Owner’s prioritization work difficult, though not impossible.
The Scrum Guide only requires to have an ordered list of everything. In an ordered list, all items have a relative rank. In the end, if a team is capable of choosing Product Backlog items for a Sprint, they certainly have some method for ranking them.
Yes and no, it depends. If a non-functional requirement is true for the entire product, it would be better to include it in the definition of “Done”. However, if a non-functional requirement is part of a particular feature, it should be included in the description of the related Product Backlog item. For instance, the team can detail it in the Acceptance Criteria.
Product Backlog Item and User Story
| Product Backlog Item | User Story |
| A reference to a capability, feature or anything we want to have in our product. | A requirement capturing technique that was originally invented for eXtreme Programming. |
| Ideally, it should have a title, description, estimation, value and rank. | The user story can have any format, though typically formulated with the following template: ‘As a {…}, I want to {…}, in order to {…}. It is often enriched with acceptance criteria. The template is rarely enough for expressing a complex need. |
| Once it is “Done”, it is done. Part of the product. | Requirements change, and so do user stories. This may induce a new body of work. |
Key Takeaways
- The Product Owner is accountable for the Product Backlog but can delegate the responsibility to the Developers.
- The Product Goal can guide the Developers even in the absence of the Product Owner.
- The Product Backlog is not a list of user stories, it is not to say defining some Product Backlog items as user stories would be wrong.
Let’s remember this from the original Scrum Guide: “As long as a product exists, Product Backlog also exists.”
The Scrum Guide – 2017
Product Backlog
The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
A Product Backlog is never complete. The earliest development of it lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. If a product exists, its Product Backlog also exists.
The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when “Done.”
As a product is used and gains value, and the marketplace provides feedback, the Product Backlog becomes a larger and more exhaustive list. Requirements never stop changing, so a Product Backlog is a living artifact. Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.
Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product. A Product Backlog attribute that groups items may then be employed.
Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.
Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning. Product Backlog items usually acquire this degree of transparency through the above described refining activities.
The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.
Monitoring Progress Toward Goals
At any point in time, the total work remaining to reach a goal can be summed. The Product Owner tracks this total work remaining at least every Sprint Review. The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal. This information is made transparent to all stakeholders.
Various projective practices upon trending have been used to forecast progress, like burn-downs, burn-ups, or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision-making.
©2017 Ken Schwaber and Jeff Sutherland.
The Scrum Guide – 2010
Product Backlog and Release Burndown
The requirements for the product that the Team(s) is developing are listed in the Product Backlog. The Product Owner is responsible for the Product Backlog, its contents, its availability, and its prioritization. Product Backlog is never complete. The initial cut at developing it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Backlog is dynamic in that it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, Product Backlog also exists.
The Product Backlog represents everything necessary to develop and launch a successful product. It is a list of all features, functions, technologies, enhancements, and bug fixes that constitute the changes that will be made to the product for future releases. Product Backlog items have the attributes of a
description, priority, and estimate. Priority is driven by risk, value, and necessity. There are many techniques for assessing these attributes.Tip
Product Backlog items are usually stated as User Stories. Use Cases are appropriate as well, but they are better for use in developing life- or mission-
critical software.Product Backlog is sorted in order of priority. Top priority Product Backlog drives immediate development activities. The higher the priority, the more urgent it is, the more it has been thought about, and the more consensus there is regarding its value. Higher priority backlog is clearer and has more detailed information than lower priority backlog. Better estimates are made based on the greater clarity and increased detail. The lower the priority, the less the detail, until you can barely make out the item.
As a product is used, as its value increases, and as the marketplace provides feedback, the product’s backlog emerges into a larger and more exhaustive list. Requirements never stop changing. Product Backlog is a living document. Changes in business requirements, market conditions, technology, and staffing cause
changes in the Product Backlog. To minimize rework, only the highest priority items need to be detailed out. The Product Backlog items that will occupy the Teams for the upcoming several Sprints are fine-grained, having been decomposed so that any one item can be done within the duration of the Sprint.Tip
Scrum Teams often spend 10% of each Sprint grooming the product backlog to meet the above definition of the Product Backlog. When groomed to this level of granularity, the Product Backlog items at the top of the Product Backlog (highest priority, greatest value) are decomposed so they fit within one Sprint. They have been analyzed and thought through during the grooming process. When the Sprint Planning meeting occurs, these top priority Product Backlog items are well understood and easily selected.Tip
Acceptance tests are often used as another Product Backlog item attribute. They can often supplant more detailed text descriptions with a testable description of what the Product Backlog item must do when completed.Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the Product. A Product Backlog attribute that groups items is then employed. Grouping can occur by feature set, technology, or architecture, and it is often used as a way to organize work by Scrum Team.
The Release Burndown graph records the sum of remaining Product Backlog estimated effort across time. The estimated effort is in whatever unit of work the Scrum Team and organization have decided upon. The units of time are usually Sprints.
Product Backlog item estimates are calculated initially during Release Planning, and thereafter as they are created. During Product Backlog grooming they are reviewed and revised. However, they can be updated at any time. The Team is responsible for all estimates. The Product Owner may influence the Team by helping understand and select trade-offs, but the final estimate is made by the Team. The Product Owner keeps an updated Product Backlog list Release Backlog Burndown posted at all times. A trend line can be drawn based on the change in remaining work.
Tip
In some organizations, more work is added to the backlog than is completed. This may create a trend line that is flat or even slopes upwards. To compensate for this and retain transparency, a new floor may be created when work is added or subtracted. The floor should add or remove only significant changes and should be well documented.Tip
© 2008-2010 Ken Schwaber and Jeff Sutherland, All Rights Reserved
The trend line may be unreliable for the first two to three Sprints of a release unless the Teams have worked together before, know the product well, and understand the underlying technology.