Two of the Scrum Masters’ responsibilities to the Product Owner are:

• Finding techniques for effective Product Backlog management;
• Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;

So let’s look at a few practical techniques for prioritising/ordering the Product Backlog.

I have focussed on qualitative methods here as I find they are the easiest for Product Owners and stakeholders to quickly pick up. Of course each person will have their own agenda when it comes to their ‘must have’ features and these features are always the most important to that individual. But people will always have a bias – I have even heard of quantative results being overruled because they did not fit with what the managers at the organisation wanted – so perhaps it is better to accept this fact, rather than pretending you’re prioritising objectively.

MoSCoW

Using this method, Product Backlog Items are categorised into one of the following:

Must have – these must be included in a product for it to be regarded as a success.
Should have – high priority items that should be included wherever possible.
Could have – lower priority items. These are generally ‘nice to have’.
Won’t have – items that won’t be implemented at the current time. However they can be reconsidered in the future.

Within each category it may be useful to further order the items.

Buy A Feature

Using the concept of gamification, this method can make prioritisation more fun, while still discovering what the stakeholders want. Simply follow these steps:

1. Provide a cost for each item that needs prioritising. This may be based on developer effort, complexity or actual cost to develop.
2. Get the stakeholders together – this works best if they meet in person.
3. Present to them the items that need prioritising.
4. Each stakeholder has an allowance of money e.g. £100
5. Stakeholders assign their money appropriately to the features that they want. They can buy individually or club together with others in order to buy more expensive items.
6. Items can be bought more than once, by different stakeholders.
7. The items can then be ordered by the amount that has been spent on them – whether this is low cost items that have been bought many times, or more expensive items that people have collaborated to buy.

Priority Poker

This works in the same way as Planning Poker. First, decide on a ranking scale for items – the Fibonachi sequence is popular (1,2,3,5,8, etc).

In a group, every person has card for each of the ratings.

The item to be ranked is read out to the group and each member selects a card based on their perceived priority. They must keep their card hidden until everyone has chosen.

Once every member of the group has selected a card, they are all revealed simultaneously.

If the selected priorities are all similar, then the group is in agreement. If there are outliers, then the differences must be discussed in the hope of aligning everyone’s views on the required priority.

The same item is then ranked again by repeating the steps above in the hope of achieving consensus. If consensus still can’t be reached it may be that the item needs refining into smaller items or that an average (median) score is used.

Alternatively the group may need to decide not on the ‘perfect’ priority, but one they can support.

Kano Model

The Kano model challenges the idea that improving every aspect of your product results in an increase of customer satisfaction. In reality, there are areas of basic expectation in a product that a customer would always expect to be there – often these can require a large amount of effort to develop. Conversely, there maybe features that would impress users but require very little effort to create.

Mandatory features – must be present in order for users not to be disatisfied

Linear features – the more of these there are, the more satisfied a user is

Delighters – Features that are high up the satisfaction scale.

The Kano model is a little more in depth than the other methods of priorisiation that I’ve mentioned, so I’ll put it into it’s own post. That way we can look at its theory in detail and see how we can use it practically when prioristing the Product Backlog – Using the Kano Model to prioritise the Product Backlog.

Duncan Halley is a certified Scrum Master (PSM I). You can read his blog here.

Follow him on Twitter: @duncanhalley