Prioritisation tools and tips for Agile projects
By Nick Butler in Agile on September 18, 2017
We recently asked you what topic you wanted us to cover next. You picked Prioritisation, so we’ve pulled together a range of prioritisation tools and techniques for Agile projects.
It’s not comprehensive—it’s more a greatest hits than the definitive collection—but it is based on our experience and our understanding of the enormous benefits you get from prioritising what you work on.
Prioritising is about choosing to do the work that delivers the most value for the least effort. If the value of all your work is the same, do that which is the least effort. If the effort is all the same, do that of the highest value.
Sadly, it’s not usually that simple. Most of the time both these factors vary.
And determining value and effort isn’t always easy either. Take value for instance. This depends on your objectives. For businesses it’s about money. For the public or nonprofit sectors it’s the outcomes achieved. In either case the value will depend on the benefits delivered to your users. Additionally, the value needs to factor in things like costs (saved and incurred), risks, and what you can learn once you’ve delivered a piece of work that you couldn’t learn before.
This post focuses on qualitative not quantitative approaches. Where we assign values to a prioritisation factor they’re relative values not absolute. If you want to start plugging in numbers you could start by reading Mike Cohn’s Agile Estimating and Planning.
You’re more likely to use quantitative prioritisation for large, complex, high-stakes projects. Spending days calculating a dollar value for each piece of work for a short, simple project isn’t usually the best use of time. You also need to prioritise your prioritisation.
Tips for better prioritisation
There are three ways you can run prioritisation exercises to get the most out of your team. Your approach should be:
Get together, print stuff out or write it down, and move things round. Play games. Have fun and have a conversation.
Who does the prioritisation
Successful prioritisation involves asking the right people the right questions. For determining business value that’s the product owner, stakeholders who know the customers and the business well, and usually the project team as well.
For estimating the effort, it’s the team, with the product owner providing clarification about what’s involved if needed.
When to do the prioritisation
In Agile projects, you prioritise continuously as part of your just-in-time planning.
One of the advantages of working in short iterations is you can focus on deciding the priorities for the next iteration but not all the future iterations. That way, as you learn new things about the project, product and how the customers will use it, you can change your priorities.
At Boost we tend to use a more intensive prioritisation process for project kick-offs. We also often use this process in the middle of a project when we start a big new unified chunk of work.
We discuss priorities before and during each iteration (usually a Scrum sprint) in the sprint planning and refinement meetings respectively.
For Boost’s internal Scrum our product owner Gavin works to keep the backlog (a team to-do list) in priority order at all time. This means that when someone finishes all the work they committed to in a sprint they can pick up the top story from the backlog.
Prioritisation during project kick-offs
Following our kick-off, we start the project with the:
- Minimum Viable Product. The MVP charts the user stories we need to finish in order to create a product complete enough that customers will adopt it. (User stories are a short description of something a customer will do when using the product.)
- Backlog: A prioritised list of user story stubs (just descriptive titles) that we’ll move onto once the MVP is complete.
At this stage we’ve not factored in effort. Because the MVP is all and only what is needed there’s no discretion to choose stories just because they’ll be less effort.
To decide which ones get tackled first we need to estimate the size of each story. Size is a relative measure of the effort in developing the feature described by the story. It doesn’t equate to any particular length of time, but bigger stories take more time.
Estimation for prioritisation
The main way we estimate the size of a story is by playing Planning poker.
Gather the project team. Give each member, apart from the product owner and the Scrum master, a hand of cards, with one card for each size story. The cards we use are either:
- a variation on the Fibonacci sequence: 1,2, 3, 5, 8, 13, 20, ?
- t-shirt sizes: XS, S, M, L, XL, ?
We take turns to read out each story. Privately we decide which size story it is. Then we simultaneously turn over our cards. If there’s variation we discuss, briefly, until we come up with a consensus.
Planning poker helps make estimating more fun and avoids the first person’s estimate biasing later discussion.
Learn more about Planning poker.
For small sets of stories you can also do relative sizing.
Print or write out each story. Take the first two stories and decide as a team which is bigger, laying them on the table with the bigger one at the top. Grab the next story and decide whether it goes above, between or below the first two. Repeat till you’re done and you have a ranked set of stories. Where it can be hard to put a number on a size, it’s sometimes easier to compare stories.
Prioritisation tools and techniques
As noted in the kick-off kit, we usually prioritise stories at project kick-offs using personas and MoSCoW prioritisation.
Prioritisation by personas
Personas are a broad brush prioritisation tool. All things being equal, we work on stories that will most benefit our most important customers, as described by our top persona.
Learn more about developing personas.
MoSCoW prioritisation divides stories into Musts, Shoulds, Coulds and Woulds. It’s the main tool we use for project kick-offs (in conjunction with the user story map).
Learn more about prioritising user stories in project kick-offs.
This is the same as Planning poker except you estimate the value of each story not its size.
Learn more about Priority poker.
Buy a feature
This is a good way of building in the real world constraint that you can’t do everything. It does this by setting a limit on the features you can have.
You start Buy a feature with a backlog of user stories.
First you need to estimate the price for each story. The bigger the story the higher the price. You might want to use Planning poker to estimate the price.
Write or print each story on a card along with its price. Add up the total cost of all the features. Then dole out play money sufficient to cover most but not all of this cost (between a half and a third of the total).
Players then decide together which features they want to buy with their limited budget.
Buy a feature makes concrete the abstract idea of resource scarcity and prompts discussions about what stories will give you the most bang for your pretend bucks.
Get more detailed instructions and templates for Buy a feature.
Write each story on a post-it note.
Draw a mini matrix on a whiteboard like the one below. The four quadrants span two axes, value and effort (size).
Place the post-its in the appropriate point along both axes. You can either agree the value and size ahead of time or discuss as you add the post-its.
You then work first on the top left, high-value small-size stories.
Weighted Shortest Job First
WSJF is a more in-depth way of prioritising than quadrants. It also prioritises by effort (the ‘shortest job’ bit) but creates a formula for factoring in value, or other weightings like risk. A common weighting is cost of delay, which is a specific way of deciding the value of a story or job.
The formula: Divide the job’s cost of delay by its size (size being a proxy for duration).
What is the cost of delay?
Cost of delay combines value and urgency. You can work it out by combining:
- what business benefits you miss out by not having the user benefits in place (e.g. revenue, cost-savings or actionable insights)
- how urgent the story or feature is.
This matrix from Black Swan Farming gives you a 5 point scale for the cost of delay (from Very High at 5 to Very Low at 1). You can then divide this by size of the story.
People often go away and work on WSJF on their own but this misses the benefits of the conversation. It’s a good idea to come up with cost of delay and effort as a team.
Learn more about Weighted Shortest Job First.
Impact mapping for prioritisation
Impact mapping is a way to link deliverables or features with high level business goals.
Usually you start with the goals and map through the relevant actors, what the actors need to be able to do (the impacts we want to achieve) and the deliverable that will let them do so. However, you can also work backwards from your backlog, and prioritise your deliverables by which of your goals they help you achieve.
Find out more about impact mapping.
Risk and prioritisation
Mike Cohn recommends using a quadrant to factor risk into your prioritisation.
If you start with the high-risk high-value work you can manage the risk and gain the value early.
Two final words on prioritisation
As both internal Boost Scrum product owner and Scrum master on external projects, Gavin has good insight into prioritisation and he sums up the art in two words: Be brutal.
By way of example he tells of a prioritisation exercise he ran with a client.
“We had a certain budget and certain time frame and we had the printed-out stories on the table. She had prioritised them and got the important ones up to the top. Then she literally picked the low priority cards up off the table, ripped them up and threw them in the bin.”
Read about our experiments with user story mapping and ‘buy a feature’ prioritisation.
Read our post about the difference between prioritising and ordering.
Get tools to measure and improve how well you prioritise so you can reduce software development risk with Agile prioritisation.