How to Easily Prioritize Your Agile Stories

What Comes First?

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.

Urgency

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

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.

Priority

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

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.

Michael

That Was Easy!

Michael

I am an independent consultant who has been leading software teams, designing, building and delivering software for nearly three decades. It’s still as exciting and enjoyable for me today as at was when I wrote my very first Hello World program and saw it spring to life in front of me.