Prioritization - the True "Secret Sauce" for Scrum Teams

May 20, 2013

So many aspects of Scrum and Agile Methods are based on common sense. One obvious example is prioritization. The seminal artifact in Scrum, the product backlog, is a list of “to do” items in priority order. The prioritization is 1 - n, not groupings of highs, mediums, and lows. The Scrum product owner creates and manages the prioritized product backlog. He/she must make the difficult decisions involved in prioritizing what often times is a list of work items and user stories into the hundreds. When coaching, I like to say “the product owner must decide between number 81 and 82 – which is truly higher priority?”

Sadly, many teams that claim they are “agile” do not even have a prioritized list guiding their development work. When this happens, the development teams are working a version of a waterfall-type project with fixed scope, fixed schedule, and fixed resources. You often hear the explicit statement “Everything is priority 1”. You also hear it in statements such as “We need it all” and “Without everything we cannot launch”. We all know how disastrous that can be. Check out the Standish Chaos Report for the abysmal performance of software project teams. While this has improved recently (thanks in part to iterative development and Agile Methods), there is still so much room for improvement. When you hear statements like this, it is likely that someone is acquiescing on their responsibility. Ask who the product owner is, and get them to build a prioritized product backlog. If you don’t like the answer, then build the prioritized product backlog yourself. And then use it. And make it visible. And make sure everyone knows you are using it!

A fundamental tenet of Scrum is scope variability. Repeat it with me: scope variability. That means that the main (and often times the only) variable in a Scrummed project is the amount of scope delivered by the fixed end date. In order to insure what is delivered at the end date is potentially launchable, ruthless prioritization is used to drive the development activities. This insures the best chance of a launch by the stated end date. Often times this means that lower-priority items are not part of the original delivery. So be it.

A true Scrum team has a prioritized product backlog, often called a “team backlog”. Items in the team backlog are at the granularity of user stories that can be completed within a single sprint. If multiple Scrum teams are working the same project, there is a prioritized product backlog called the “release backlog”. The release backlog contains items at the feature level. By looking at the release backlog, the Scrum teams can synchronize their efforts towards development of the highest-priority features. Typically, a feature is made up of multiple user stories. For larger organization, there is a prioritized product backlog called the “portfolio backlog”. The portfolio backlog contains epics, strategies, technology advances, and the like that are considered important to the business viability. Typically epics involve multiple features. Dean Leffingwell gives a wonderful description of how Scrum scales up, including the use of the different product backlogs in his book “Agile Software Requirements”. It is a must read for all agilists.

Prioritization is the true “secret sauce” of Scrum. It is a simple concept, but has powerful and far-reaching consequences. Prioritization allows the development teams to focus. Prioritization allows the stakeholders to make a righteous decision on launching the product by the stated end date. Prioritization keeps the project team members sane. Prioritization is your friend. Without it, your team is not agile.

Back to Blogs