Backlog prioritisation - Making hard choices

One of the biggest issues with backlogs is deciding what to keep in and what to take out. If you say to your customer something like "imagine this is the last sprint, what would you choose?" the business sponsors tend to know, in the back of their minds, that this is, usually, not true. Therefore they don't really make hard choices.

I recently completed a couple of projects where we used different approaches to this problem. Both of these focussed on discovering a minimum viable product and a set of releasable customer journeys.

The snake approach

The first technique was based on the backlog snake idea. This is where you print out the backlog and make a long line around the room. The key part of this is to establish various key points along the line. I have a nice video of this here:

Another technique I used here was to use self organisation to maximise the sorting. Here I give an objective to achieve and don't say how to go about it. The objectives were to:
  • create a line of requirements represented on the card provided, 
  • place the highest at one end of the table and the lowest at the other, 
  • make sure the line is continuous and be no more than one card wide. 
  • place objects of your choice representing release points along the snake.
In this case I used objects in the room to represent where the cut off points could be. A good technique for establishing these points was to talk about alpha, beta, live and first update releases. An alternative is the MoSCoW approach, although there is a danger that everything is a must have at some point, at least in the eyes of most customers.  The session was divided into 30 minute segments. At the start of each segment they reviewed their progress and planned the next 30 minutes, changing their approach at this point where necessary.

The Casino - or having to play hardball!

The other technique I developed with a colleague was used in a very difficult situation where a release was imminent and the customer was still expecting much more than was possible. We knew from the latest forecasts showed a re-setting of expectations was needed and there was a risk that this news would create problems for the business and some hard decisions would be needed. 

The technique we used was an expression of value using the snake idea which we had used to good effect and some poker chips. 

The snake (see above) was laid out and the customer ordered the backlog targeted for release. The customer were given poker chips which totalled to the number of points estimated for the amount of work that could be done for before the next release. Some of the chips were different colours i.e. there was a contingency set which could be used if they wanted to sacrifice some flexibility. They then got to work "buying work" and here the strange thing happened, firstly the customer realised for the first time that this was not a theoretical exercise and there weren't enough chips to buy the things they had deemed as the minimum viable product, secondly they made different prioritisation choices with the poker chips then originally; bringing some items forward and some out of MVP.

The lesson here is that whatever decisions are being made during prioritisation they are to some extent arbitrary, the key is to present the choice in the right way so that the consequences of the choice are clear. The other point is that "must haves" or minimum viable products are often not minimums - you must tease out smaller releasable increments otherwise we start boiling the ocean.


Popular posts from this blog

In sprint cumulative flow in Jira

Value vs effort - a visual approach

Agile is not different words for the same thing