2006

One of the cool things in Agile is the way we prioritise stories – functional and technical requirements. With the stories being cards it is easy to shuffle them about on the table and move them up and down a hierarchy of importance. Trouble is such a simple idea often fails to provide the simple desired outcome.

Problem 1. Prioritisation is difficult. Bad experiences with IT often lead the business to believe that anything given a low priority is effectively being de-scoped and thus are reluctant to mark anything low.

Problem 2. Relating the prioritisation back to the business objectives. If it is not made clear before (and during) the exercise that the prioritisation should be based upon business objectives (for example we are doing this project to reduce costs or drive revenue) stories tend to be prioritised according to the personal agendas. So the marketing stakeholders will be pushing content management to the top of the pile, change management will be pushing training and support tools, IT will be pushing diagnostic tools… and the high priority stories become a disjointed list of features that do little to address the business objectives.

Problem 3. The language of prioritisation. Often it is not clear why we are doing the prioritisation. The business wants the project with all its features – otherwise why would it have identified them in the first place. MoSCoW – must have, should have, could have, want to have softens the language of “high, medium or low” but there is still a bucket of “W – want to have” which in effect is perceived as “won’t have”. Doing away with language altogether can be more effective, but ranking the stories tends to lead to clusters and moving things out of the clusters (i.e. assigning lower priority) tens to be painful.

Problem 4. Highest priority stories do not make a release. Let’s be clear, more often than not the objective of the prioritisation exercise is to drive some sort of release plan. To be successful a release should constitute a meaningful and coherent collection of stories that drive business benefit. Logging in to your shopping cart is deemed as being of high business benefit, password reset and logout low priority. Yet without these the release is incomplete.

So what to do?

The concept of a tree is useful, there are roots that are essential, a trunk, branches and leaves (and the leaves can be pruned by the conscientious gardener to produce the perfect tree), but this approach does not really address problem 4.

We’ve started trying a new approach which seems to work. You are open and honest about the purpose of the exercise. It is all producing a high level feature plan to inform the way we will develop (and maybe release) the software. We make it clear that it is not about fixing scope or producing a release plan that we will all be held to (things change right?). You lay all the cards on a central table, spread out and not overlapping. There are four separate tables labelled A-D (or however many ‘releases’ you aspire to). These are the following:

Table A – If you could launch the product tomorrow, what is the bare minimum you would require to satisfy immediate requirements of customers and the business?

Table B – What would your customers require next? What would does the business need next?

Table C – You’ve been live for a while, what comes next?

Table D – These are the final features that are important but not mandatory on tables A-C

It is important that the cards do not have titles on them. That way the people prioritising them must read them (and understand them) before assigning each card to a table. You then prioritise in time boxed iterations (it can be useful to have an egg timer to help this). In the first iteration you ask everyone as individuals to pick a card from the centre and place it on a table. Remind them to think about the business objectives. The only rule is that the tables must contain a roughly even number of cards. (If table “A” becomes “full” a gate keeper can prevent more cards from being added to it. Remember this is just the first iteration).

The second iteration involves everyone standing around Table A and looking at is as a meaningful release. Does everything in there meet the business objectives? Is it self contained? The objective of this iteration is to exclude items that could come later (for example “data migration”. For the first release maybe it would just be a pilot and we could manually put customers on the system). There may be comments that there are things missing – it doesn’t matter, we will find those later. Again, time box the iteration and then move on.

The next iteration focuses upon table D. What needs to move up? Ten minutes then move on to tables C and D. These might be hardest; it is easy to agree what must be delivered early and what can come last, but the stuff in-between can be a challenge. Maintain momentum by always returning to the business objectives, and what are the most important to deliver on first. Once all tables have been visited a final iteration walks through them all. Again, it is made clear that this is not something we need to be held to, but it informs how we move on; to drilling into more detail on the high level stories and producing sufficient insight to make meaningful estimates. Estimation? Now that’s a different story.