Planning

Token Prioritisation

My favourite technique for prioritising a backlog is to use tokens. I think the first time I encountered this method we used sticky dots but after much trial and error, I now use physical tokens as having something quantifiable and real in your hand seems to help to prioritise the work and people tend to be more engaged. This would work with any token (Agility Cards, Poker Chips, magnets, jelly beans, etc…). Using this technique you can prioritise large backlogs (up to about 100 items) in just a few minutes. The output is a consensus-generated prioritised list that can be then talked about and modified as necessary. This is a lot easier to do once an initial order is established.

Pros/Cons

  • Very interactive – engages people really well
  • Involves the whole team – everyone’s voice is heard
  • Runs the risk of not being a carefully thought about order

Start by giving some cards to each ‘player’. A player is anybody who is interested in the priority of the work, this should include the business and any technical staff involved.

My suggested values are as follows:

  • 1x Black Cards (10 points)
  • 2x Green Cards (5 points)
  • 2 Orange Cards (2 points)
  • 3 Red Cards (1 point)

This gives a good number for a large backlog, for smaller backlogs use a smaller number of cards.

Setup

If your tokens don't have values on them, write the values somewhere clear that everyone can see. Print and lay all the items to be prioritised down so that the players can see all the requirements.

How it works

Ask the players to vote for which items should be prioritised with their chips. They can put multiple chips on 1 item if they like. I like to use a time limit of 5 minutes, the timebox helps them focus.

Add up the values, write the total on the item and prioritise based on these values.

As with any prioritisation method, this initial order should be a cause for a conversation. I would expect the Product Owner to take this information and re-prioritise as necessary but the end-to-end time should be greatly reduced.

What other prioritisation techniques do you use? What tokens are best?

MoSCoW Prioritisation

The concept of proving an end-to-end process is fundamental when starting Agile projects. With the teams I coach, I encourage them to get something (anything) in use/live as soon as possible. This engages the customer immediately, creates immediate learning and highlights unexpected bottlenecks in the end-to-end process.

This is very similar to a ‘Hello World’ software development concept that uses the smallest amount of code possible to write the phrase ‘Hello World’ on the screen. It is one of the simplest programs a developer can write and is often used to show that a language is installed correctly, the code compiles successfully and that the release environment is capable of delivering value to an end user.

BALANCING THE MVP

The ratio of the Minimum Viable Product (MVP) to other items on the backlog has a direct relationship with any time constraints you have. As you add more and more items to the MVP it puts more pressure on any deadlines you have, potentially forcing your hand to delay a release rather than negotiating scope that could wait until later. My advice here is to be harsh with your MVP, if you get it all done and have time for some other priority features then that's great, at least then you have the option.

MOSCOW

We can use the MoSCoW method to help prioritise and identify our Minimum Viable Product. It works by splitting the backlog into 4 categories:

 

MUST

The items in the ‘Must’ category are critical in order for the product to be usable. This is your MVP. To validate the items, take an item in your backlog and ask yourself this question:

If I had completed everything else on the backlog and this was the only remaining item left to do before getting this product in use, would I go live anyway?

If the answer is yes, the item is not part of the MVP, if the answer is no, then it probably is.

Items in your MVP should be prioritised to optimise for feedback and build speed, not necessarily customer value

SHOULD

The items in the ‘Should’ category are items which add a lot of value but you could initially go live without.

Items outside your MVP should be prioritised by customer value.

 

COULD

Your ‘Could’ items make up your nice-to-haves. These are the go-to place if the scope of a release needs adjusting.

 

WON’T

These are the items that after discussion don’t make it into the release or backlog. They are still useful to store and call out explicitly so that the stakeholders are clear what is not going to be done

 

HOW TO OBTAIN THE DATA

DELPHI METHOD:

Add MoSCoW tokens to planning poker or delphi estimation to easily identify a consensus view.

AFFINITY METHOD:

Place 1 copy of the token on the table with print outs of the items to be prioritised and ask the team to move the items as necessary into each category. Encourage conversation as necessary!

What problems could you forsee with MoSCoW? How does your organisation determine their MVP?

5 Deadly Assassins of Product Planning

When thinking about prioritisation for a new product. There are 5 assassins waiting to strike. They sit there, hidden in your backlog, undetected until the time is right and just when you think you're making progress, they make themselves known. In this blog we talk about the 5 assassins of product planning and strategies for how to combat them.

 

THE ASSASSINS

Data Migration

If you are expecting that data you’re planning to migrate from an old app is going to come without a fight, think again. The way you extract, transform and load the data can be extremely unpredictable.

Data Quality

It’s not just about moving data, but also about the data itself. If the data isn’t clean, in the right format and consistent you are likely to run into problems down the line.

Data Integration

Perhaps you’re not intending to move data at all but are planning to integrate with another product. Even if the API is fully documented, it doesn’t mean it will work exactly as written.

Path-To-Live

We need to understand and prove how our software is distributed, all the way through to live. There’s no value building software if it never sees a live environment.

Third Parties

Third parties have been known to make some pretty bold claims. Outsourcing seems like such a great idea – new relationships are particularly at risk of introducing dependencies that you can’t control which cause headaches down the line.

 

COPING STRATEGIES

If you suspect any of these assassins are lurking in your product, my recommendation is that you prioritise a small, demonstrable, part of your product as soon as possible that tests any assumptions we might have. Then you have the most time available to react if something is unexpected.

What you're looking for is a tracer bullet style piece of work - a production quality piece of valuable work that proves an end-to-end system. It's all about cutting that initial feedback loop down to as small as possible.

Let's look at some examples:

  • Data Migration - A script that loads one piece of data from the real source, transforms it into target format and saves it into your database.
  • Data Quality - A script that pulls in 10 random records from source data and displays it on the screen for review by a human.
  • Data Integration - Sending and receiving a request to an API for a single piece of typical data.
  • Path-to-live - Take the phrase 'Hello World' through to a production environment and display it on a web page. 
  • Third Parties - Third parties are a little different, I would look to prioritise a feature which has a large amount of required feedback from the customer and I would want to see demonstrable releases to a production environment every week. 

The above are only examples, I'm sure in your specific context you have particular needs that can't be addressed by generic content. So what's different for you? What assassins do you have?