RSSPrioritisation requires us to decide how important an item is. If everything is high priority, then everything is equally important. This means in effect that nothing is a priority, so there is only a slim chance of delivering what the customer really needs. Prioritisation is part of product backlog grooming, and it directs the team’s work by focusing the team on the most important items. It also freezes the backlog contents progressively. As items are detailed according to their priority, flexibility is built into the process and allows delaying decisions about the lower priority items, buying the Scrum team more time to evaluate options, gather feedback from customers, and acquire more knowledge. This ultimately results in better decisions and a better product. The reminder of this posts explores four useful factors to prioritize the product backlog: value; risk and uncertainty; releasability; and dependencies.
Value
Value is a common prioritisation factor. We certainly want to deliver the most valuable items first. But what makes a product backlog item valuable? My answer is simple. An item is valuable if it is necessary for bringing the product to life. If that’s not the case, the item is irrelevant; it is excluded from the current release or product version. The Scrum team either de-prioritizes the item and places it right at the bottom of the product backlog or better, discards it altogether. The latter keeps the product backlog concise and the Scrum team focused. If the item is important for a future version, it will re-emerge.
Risk and Uncertainty
Risk is an intrinsic part of software development; no product can come to life risk-free. Correlated with risk is uncertainty. The more uncertainty there is the riskier the project is. Because risk and uncertainty influence product success, uncertain and risky items should be high priority. This accelerates the generation of new knowledge, drives out uncertainty, and reduces risk. If the Scrum team, for instance, is unsure about some aspects of the user interface design, then the relevant design options should be explored and tested by gathering feedback from customers and users. Tackling uncertain, risky items early creates a risk-driven approach that may enforce early failure. Failing early allows the Scrum team to change course while there is still the opportunity, for instance, to modify the architecture and technology selection.
Releasability
Releasing early and frequently is a great way to let the software evolve into a product that customers love. It’s also an effective way to mitigate risks. If the Scrum team is uncertain about if and how a feature should be implemented, then early releases can answer this question. Being able to release product increments early and frequently should therefore influence the product backlog prioritisation. Each release should provide functionality that is useful to customers and users and that generates the desired feedback. Note that it’s usually not necessary to fully implement a theme; a partial implementation is often sufficient for early releases.
Dependencies
Weather we like it or not, dependencies in the product backlog are a fact. Functional requirements, for instance, often depend on other functional and even non-functional requirements. And if several teams work together, dependencies between them can influence the prioritisation. Dependencies restrict the freedom to prioritize the product backlog and influence the effort estimates; the item others depend on has to be implemented first. You should therefore try to resolve dependencies whenever possible. If that’s not an option then the dependencies are likely to influence the product backlog prioritisation. Two dependent items may have to be implemented in the same sprint, for instance.
Find out more about how to prioritise your product backlog in my book Agile Product Management with Scrum: Creating Products that Customers Love.
