Michael Lant

Software Archictecture, Development, Agile Methods and the Intersection of People Process and Technology

Agile, Project Management, Scrum, Software Development, Technology

How to Easily Prioritize Your Agile Stories

What Comes First?

Saturday Scrum Sprint 03
Index cards for Saturday morning chores (alandd from flickr)

You’ve spoken to all of your stakeholders, maybe had a workshop or two, gathered all of the input, defined requirements and converted it all into stories, and now you have writer’s cramp from printing them all out onto index cards. You’ve now taken over the conference room and spread your cards out on the table so that you can organize them and figure what goes into your first sprint. So really – what stories come first? Marketing, Sales, Finance, and Operations all have their priorities. Your lead architect says that none of it can be done until the architecture is nailed down – and then of course there is the CEO and her view of what needs to be done first – Oh, and don’t forget the customers. It’s all important; otherwise it wouldn’t be on your index cards would it? Some things are definitely more important than others – but which ones? Scott Ambler says that 85% of all features built into software products are either rarely used, or never used at all. So as much as some stakeholders might think that a particular product feature is essential, it is highly likely it will end up being one of the 85% that go unused. One of the fundamental reasons for using an Agile methodology is to focus on the things that bring the greatest value, so how do you actually determine which stories provide the greatest value and are thus scheduled first? To be effective and obtain consistent, repeatable results requires a system or process that is quick, easy to use and consistently applied.

The quick answer is to rank all of the cards on a scale of 1 to 10, or 1 to 100 if you need finer differentiation, and then sort them in order from highest to lowest priority. This is a pretty common approach, but it is challenging to apply a single numerical value to what is usually a multidimensional question. Do you rank your stories by the CEO’s sense of urgency, the amount of money a customer will pay you to do it, what marketing says is essential, or to placate a cranky stakeholder? Any of these criteria might be valid, but how do you know which ones are more important than the others, and when does one criterion apply but not another? I found that looking at these choices from a two dimensional perspective, and by having guidelines for the application of each of two vectors makes the decision making process much more straightforward. You could in actually use any number of dimensions or vectors you wish, but using more than two causes the process to get bogged down in the fine details and makes the otherwise simple calculations more cumbersome. Perhaps more importantly, it is very difficult to represent three or more dimensions in a two dimensional world such as a computer screen or on an index card. So the number in this approach is two.

So now that you’ve decided to be merely two-dimensional, what are you going to choose as your assessment vectors? In truth, you can use any two you wish. I use Time as the first vector because time is almost inevitably the fundamental constraint on all projects and it is the one finite resource. Most importantly, Time is the basis for arranging and sequencing our work. Time for the purposes of this methodology, is also thought of as Urgency.

The following table lists a set of guidelines that are suggestions for selecting each one of the five possible Urgency (or Time) vector values. It is important to keep in mind that guidelines are suggestions, and you are free to define your own criteria. Regardless of what you choose, keep your guidelines as general as possible because the more specific and detailed your guidelines become, the less useful they will be.


Value Guidelines
  • Extremely time constrained.
  • Extreme level of dependency of other items on the completion of this task
  • If not completed immediately there is little or no value to doing it.
  • Highly time constrained
  • High level of dependency of other items on the completion of this task
  • Important to go into the next sprint because of customer or contractual requirements
  • Moderately time constrained
  • Moderate dependency of other items on the completion of this task
  • Desirable to complete in the next one or two sprints
  • Minimally time constrained
  • Minimal dependency of other items on the completion of this task
  • Completion in the next two or three sprints is adequate
  • Not time constrained
  • No dependencies
  • Little or no impact

So what about vector number two? I use Business Value. The category and the guidelines are purposely generalized so as to avoid debates about whether or not something is in the list and is thus applicable or not applicable as a criterion. It also leaves rating open to interpretation by different stakeholders so that the numbering system does not get gamed or used as a lever by different stakeholders to manipulate the process. Business Value could thus mean the amount of revenue that might be generated or lost, effect on brand or reputation, performance issues, security concerns, etc… It is up to the team to decide in each case what the Business Value guidelines should be, and how to classify each item.

Business Value

Value Guidelines
  • Extremely Important to most or all customers
  • Extreme impact on brand or reputation
  • Critical to the success of the business
  • Important to many customers
  • Significant impact on brand or reputation
  • Significant competitive advantage
  • Important to a moderate number of customers
  • Moderate significant impact on brand or reputation
  • Moderate important competitive advantage
  • Important to only few customers
  • Minor impact on brand or reputation
  • Minor competitive advantage
  • Important to only a few or even no customers
  • Little or no impact on brand or reputation
  • Little or no competitive advantage

If you run an internal IT shop, some of the Business Value suggestions may not be relevant. If, however, you run a small bakery and your project is opening a new location, these suggestions might all be relevant. In either case, use what makes the most sense in your situation.


Now what? We have some nice numbers and suggestions for how to match our backlog with these numbers, but what does that tell us? By themselves, not much, but if we put them together, we can use the two vectors to assess the Priority or ranking of the story. To do this, we simply multiply Urgency x Business Value and the product of these two numbers is the Priority. The result is a number ranging between 1 and 25.

Priority= Urgency x Business Value

Priority = Urgency x Business Value

Priority Ranges

I then break the values into ranges with a colour assigned to each range. For each range, I apply a ranking value as shown in the chart below. I use four ranges. Four seems to be enough to cover the necessary set of Actions and it has the advantage of fitting nicely into a chromatic scale from green to red. Experience shows that using five ranges causes people to obsess a bit more about their Business Value and Urgency ratings and slows down the process while not adding any real value. Five steps would also require an intermediate colour like an orangey-red or a greeny-yellow. Forcing people into colour discussions like this detracts from the ease and clarity this system tries to promote. Three steps are not enough – in particular because there is no way to accommodate the red or critical valuation. The particular selection of colours also maps to the mechanism I use for prioritizing bugs which I will discuss in an upcoming issue.

Agile Story Priority Ranges

Agile Story Priority Ranges

Using the System

So now you have this nice way of ranking the importance of your stories and a nice colourful chart – how do you use it? At first blush, this may appear to be a lot of work with little value. In practice, this is a very quick and simple exercise and it gets you to a decision point pretty quickly. The fact that it is a system makes it predictable, and the 10 minutes it takes to learn and implement will be recouped in your first sprint planning session.

The way I approach using the system is very simple. I leave a space in the upper right hand corner of my story cards. In that corner, I write the three numbers representing Urgency, Business Value and Priority; always in that order. When prioritizing a story, I do a quick assessment of Urgency and Business Value, and then simply multiply the two numbers together to get the Priority number. Then using a highlighter, I colour the Priority number according to the chart above. That’s it. It should take about 10-20 seconds per card. Some cards will require substantial debate amongst the stakeholders and that might be appropriate, but don’t waste your time on differentiating between green and yellow ratings. Instead focus on the red and orange, and then the obvious yellows. Once you’ve got them all rated, simply sort the cards according to their numeric value and you are done.

As you plan for each new sprint, review the ratings of each card in your backlog and change the ratings as appropriate. Some things will increase or decrease in their valuation, and there will most likely be new stories introduced, but again, do not spend much time at the green end of the spectrum. Instead stay focused on the high priority items

There you have it, a quick, easy to learn, easy to use system that will give you consistent, repeatable results.

I’m looking forward to your feedback. Please leave your comments below.


Easy Button

That Was Easy!


  1. Jack Harvey

    August 5, 2010 at 9:18 am

    Great thought on how to combine two factors to determine priority. Your assumption though is the project (product) has already been approved for work, correct? If so, this approach makes good sense.

    Obviously there are two stages for internal IT shops.

    Stage One is the various project requests received by IT where you are considering what projects to take on as an organization. That decision involves the team (who help determine complexity of each project) but the decision about which project to pursue and when is made by others.

    Stage Two is working with the team and stakeholders to plan out the project. This is where I believe applying your approach makes some good sense.

    1. Michael

      August 5, 2010 at 10:48 am

      Hi Jack,

      Thank you for the thoughtful comments.

      For the most part “Yes” you would already have a project approved. That, however, does not mean that you cannot use this same approach for prioritizing projects within the organization. If you step up a level or two and think of a project in terms of its Business Value and its Urgency, you can use exactly the same approach. This then becomes a really effective way to rate project priority relative to any other project. As to who decides which projects are initiated, that’s where the discussion begins. Various stakeholders may differ in their assessment of either the Business Value or the Urgency. Marketing may rate the server upgrade project very low on their list for both Business Value and Urgency. The IT department will likely have a different view. This is where the guidelines for the ratings help to achieve a common understanding. A formulaic based conclusion is unlikely in such a scenario, but it can form the basis of a structured discussion that leads to a conclusion.

      In truth, this method can be used as a basis for comparison of any number of things in a common set. If you read some of my other articles on Risk and Defects, you will see that I use exactly the same matrix based approach. The labels on the X and Y axes change for each function, but the methodology remains the same. Using the same matrix approach across in many areas allows people to reuse their learnings.

      Thanks again for your comments.


  2. Alexandre de Oliveir

    June 1, 2010 at 10:54 pm

    This is pure art!

    If you allow me to advance the idea a bit, a nice thing to do is apply weigths to the vectors. What if the priorities don’t have the same importance? Let’s say urgency is 70% important and business value is 30%.

    P = (2 x 0.70) x (4 x 0.30) = 1.68
    where 2 is the priority given to Urgency and 4 to BV.

    Indeed, it works better with 3 vars or more. Portfolio Management usually uses this technique due to the complexity it deals with.

    1. Michael

      June 2, 2010 at 10:03 am


      You present an interesting idea. I might be tempted to use this approach in projects where precision is essential and the outcome is critical – say aircraft guidance systems. In projects like that, I would likely lean more to PMBOK or CMM methodologies where the process places a high value on the data of the process. While your suggestion is likely more precise, Agile places a higher value on human factors in project management and this is where it might be problematic. I have used weighting in the past and have experienced mixed results. I find it to be cumbersome insofar as it is extra work, difficult to explain and equally difficult to understand unless you are a project manager. The math is also harder (I can’t do it in my head) and the more factors included, the easier it is to hide behind numbers and/or game the system. This implies more structure and discipline (process) and the farther it takes away from some of the Agile ideals of being lightweight and self-organizing.

      The weighting in my suggested methodology is actually implicit. What I should have made clearer in the article is that the ratings are negotiated amongst the team. Marketing may say that a particular feature has a Business Value of 5 and an Urgency of 5, Development may say it is 3 and 3 and Sales may say 5 and 2. The three groups need work it out amongst themselves and achieve consensus. In so doing, they are implicitly negotiating the weighting.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.