I’ll never forget the day when I suggested to the product manager of a new health-care product to prioritize the use case pile in front of her. She looked at me, her eyes widening, and replied, “I can’t. They are all high-priority.”
Prioritization requires deciding how important an item is. If everything is high-priority, 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. It’s the product owner’s responsibility to ensure that the product backlog is prioritized. Like the other grooming activities, prioritization is best carried out by the entire Scrum team. This leverages the team’s collective knowledge and generates buy-in.
Prioritization directs the team’s work by focusing the team on the most important items. It also freezes the backlog contents progressively. As mentioned before, items are detailed according to their priority. This builds flexibility 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.
Since individual product backlog items can be very small and therefore difficult to prioritize, it’s useful to prioritize themes first. We then prioritize the items within and, if necessary, across themes. The remainder of this section explores the following factors in prioritizing
the product backlog: value; knowledge, uncertainty, and risk; releasability; and dependencies.
Value
Value is a common prioritization 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 reemerge.
Before including an item in the release, decide if the product could still achieve the desired benefits without that item. This helps create a simple product, a product that implements the minimum functionality, as discussed in Chapter 2. Apple, for instance, shipped the first- and second-generation iPhone lacking a copy-and-paste functionality without damaging the product’s success. If the item is indeed required, explore whether there is an alternative that achieves the same benefit but requires less effort or time or reduces unit cost. Even though this sounds like a no-brainer, teams can be constrained by hidden assumptions and do not always evaluate all relevant options.
Don’t just scrutinize new requirements. Reexamine existing ones as well. Superior alternatives often arise after the Scrum team has learned more about customer needs and the solution being developed. Simplify, prune, and strive for order—like a gardener pulling out the weeds and trimming the shrubs.
When in doubt, exclude a requirement from the release and ship quickly without it—just as Google did when the company developed the first release of Google News, an application that aggregates news from around the world. Developers could not agree whether to filter the news by date or by location. So Google decided to release the new product without either feature. Shortly after the product’s launch, requests for new features started to come in. Three hundred people requested filtering by date, while only three wanted to filter by location—a clear indication of which functionality should take priority. If Google had released the product with both features, the release would have consumed more time and money and it would have been harder to get feedback on which feature was more important. By putting out an intentionally insufficient product, Google quickly discovered what to do next.
Knowledge, Uncertainty, and Risk
“Risk is an essential characteristic of product innovation. Every decision regarding a project—whether made explicitly or implicitly— has risk associated with it,” write Smith and Merritt (2002, 4). Risk is therefore 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. Uncertainty, in turn, is caused by a lack of knowledge. The less we know about what to develop and how to do it, the more uncertainty is present. Knowledge, uncertainty, and risk are therefore interlinked.
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, the relevant design options should be explored and tested by gathering feedback from customers and users. If the team does not know whether a third-party database access layer should be used, requirements triggering database transactions should be implemented early so that the different options can be evaluated. Note that risk can also hide in the infrastructure and environment, including a build process not yet set up or the Scrum team not being colocated.
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, or to adjust the team composition. A risk-driven, fail-early approach can be difficult to accept for individuals and organizations used to traditional processes, where problems and impediments surface late in the game and are often perceived as bad news rather than an opportunity to learn and improve.
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, early releases can answer this question, as in the case of Google News discussed earlier.
Being able to release product increments early and frequently should, therefore, influence the product backlog prioritization. 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
Whether we like it or not, dependencies in the product backlog are a fact. Functional requirements, for instance, often depend on other functional and even nonfunctional requirements. And if several teams work together, dependencies between them can influence the prioritization, as further discussed in Chapter 4. Dependencies restrict the freedom to prioritize the product backlog and influence the effort estimates; the item on which others depend has to be implemented first. You should therefore try to resolve dependencies whenever possible.
Combining several dependent items into one larger one and splitting the items differently are two common techniques for dealing with dependent user stories (Cohn 2004, 17). Let’s look at two sample stories: “As a user I want to write a text message” and “As a user, I want to write an email message.” They are dependent because both stories require a text-processing capability. If we implement the text message story first, the effort of the email message story is reduced, and vice versa. The first option is to combine them into a larger story. This is not appealing because it would result in a big compound story. The second option is to slice the requirements differently. If the common functionality is extracted into a separate story—“As a user, I want to enter text”—the two original stories are no longer dependent on each other. As such, their estimates are no longer influenced by the order in which they are worked on.
Source: Pichler, Roman. Agile Product Management with Scrum
Do you have any questions? Ask us
