By Nick Butler
Tags: Agile
When we asked our readers which topic we should cover next, the winner was Prioritisation. So here are 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.
The tools include:
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 not that black and white. On top of that, determining value and effort isn’t always easy either.
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. Value also depends on your objectives. For businesses that tends to come down to dollars. For the public or nonprofit sectors, it’s the outcomes achieved. In either case the value will depend on the benefits you deliver to your users.
You also need a realistic estimate of the effort. To help with this, we cover a couple of simple techniques for sizing pieces of work.
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.
There are three ways you can use these prioritisation tools to get the most out of your team:
Get together, print stuff out or write it down, and move things round. Play games. Have fun and have a conversation.
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 development team. The product owner can provide clarification about what’s involved if needed, but shouldn’t try to influence the estimate.
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 times. 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.
You start your prioritisation when you start the project. You can find out about our usual approach in our posts on User Story Mapping and Prioritising User Stories.
Following our kick-off, we start the project with the:
At this stage we’ve usually not factored in effort, because there are too many unknowns. 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.
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:
We take turns to read out each story. Privately we decide which size story it is. Then we simultaneously turn over our cards. (You can do something similar by simply writing the sizes on post-its.) 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.
As we note in our Agile project kick-off kit, we usually prioritise stories at project kick-offs using personas and MoSCoW prioritisation.
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.
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 about half this cost.
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.
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 risk and gain value early.
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).
Cost of delay combines value and urgency. You can work it out by combining:
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 the cost of delay and effort as a team.
Learn more about Weighted Shortest Job First.
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.
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.
Photo of people in queue by Paul Dufour on Unsplash
