What is the Product Backlog?
Let’s borrow the definition from The Scrum Guide :”The Product Backlog is an ordered list of everything that is known to be needed in the product”.
Thus, the product backlog lists the not yet implemented requirements of a product. If something has been added to the product, should not be on the backlog anymore. Hence the name, backlog – the list of items yet to be done.
Ordering the Product Backlog
The list is ordered, so the requirements are ranked. Product backlog items are implemented in the same order as they appear in the product backlog. Deciding about the order is usually the product owner’s responsibility. In a corporate environment the product owner has to take into account the needs of the stakeholders and other factors, for instance, the importance, urgency, value, size, dependencies of the backlog items, or whatever else seems adequate. It is worth mentioning that many agile experts, what is more, even earlier versions of the Scrum Guide strongly recommended using the ROI for ordering the product backlog. However, no one ever created a generally applicable method for estimating the ROI thus this recommendation was seriously flawed.
During iteration planning, the product owner can change the order of the list and can take into account other factors to choose backlog items for a given iteration. For example, if multiple large items would not fit an iteration, the product owner can choose from the smaller ones to use the capacity of the team. If the team has different specialists, the product owner may choose items to use their capacities respectively. If the backlog items would not form a coherent Scrum sprint goal, the product owner may reorder some of the items. This way the product owner can maximize the value delivered by the team.
Eliciting Product Backlog items
Unlike an upfront specification, the product backlog is never meant to be complete. In the beginning, the product backlog can be a simple draft, a list of achievable. As time progresses and people learn more about the product and the environment, the backlog would change and evolve. For this reason, normally there is no need to immediately elaborate all items added to the product backlog. Items on the top of the backlog should be ready for implementation, the rest can be elicited on the way, e.g. through backlog refinement. Teams may use a definition of ready: backlog items should meet this condition before they are taken to iteration planning. Definition of ready can be anything a given team or organization finds suitable, for example, ‘item is estimated by the development team’, ‘QA has approved the acceptance criteria’, ‘stakeholders signed off the specification’, etc.
The activity of uplifting backlog items is called backlog grooming or backlog refinement. Teams typically organize events for this purpose, however, one-on-one meetings can also take place. There are no common formalities, every team chooses their own practice. The refinement usually requires cooperation between the development team and the product owner. A typical event held with this purpose is the storytime. This event serves for introducing new stories to the development team.
Format of the Product Backlog
The product backlog is rather an abstraction than the product specification itself. That is to say, agile recommends user stories for specifying requirements, however, the product backlog does not have to include the stories. The goal of the backlog is to maintain an ordered list of them. For example, if a team uses JIRA to maintain the product backlog, they can still maintain the specification in a different tool and reference it in JIRA. If a team uses plainly Excel, they can still specify everything in Word. If a team uses Kanban cards, it is even more straightforward to specify the items somewhere else.
Since the product backlog is a list of ‘everything’ it is practical to mark or group the items based on different criteria. If multiple teams work from the same backlog they may find it useful to mark their own items. When a product has multiple features, it may be practical to use features for grouping the items. When larger requirements are broken down to smaller user stories, we can use epics to maintain the integrity of the larger groups. Themes organize the items thematically.
Estimating Product Backlog Items
There are various estimation techniques (agile or traditional) available. In an agile process the developers or the development team is entitled to 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 small items can be estimated relatively accurately, large items, on the other hand, with much bigger uncertainty. Therefore the estimation is always a Fibonacci number: there are bigger gaps between bigger numbers. There are further similar approaches is, e.g. using the powers of 2, or T-shirt sizes. The unit of the estimation is typically not a unit of time, 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.
In order to improve the accuracy of the estimation, teams may use further collaborative techniques, such as the Planning Poker. The idea of the 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, the average is accepted.
Velocity
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 whether a sprint is overbooked, good input for estimating the delivery of a large list of items (e.g. embodying the minimum viable product) and for some extent an indication whether the team is improving. However, velocity of different teams cannot be compared to each other.