A common sight in agile shops is the product owner shuffling his user stories.
"This before that. Oh this is a good one. Ooh, move that one to later."
It sure seems that many people use a prioritization scheme based in opinion, deal-of-the-day, and "whoever I talked to last."
In Requirements That Work we recommend a prioritizing formula grounded in market problems: how many people experience it and how bad is it?
In a recent session, Adrian shared this scale representing the impact of the problem on customers:
50: solving the problem will make money for customers
40: solving the problem will save money for customers
30: they think it will make/save money
20: an existing customer wants the problem solved
10: a cool feature idea
The challenge of prioritizing is that we have more ideas than we have resources. Don't you? So we must learn to prioritize.
And what did we learn from Star Trek II: The Wrath of Khan?
"The needs of the many outweigh the needs of the few… or the one."
When prioritizing, choose a scheme that is simple and objective, which aligns the product strategy with the market and its problems. Try to use a formula to represent the product strategy so that your team makes changes to the formula and doesn't just move around individual items.
What is the impact of the problem on the persona? Let's get that right.
What scale do you use?
