Deciding on priorities
There’s always a long list of things you could work on when developing a product or service. But you’ll usually have a limited amount of time, materials or skills available.
Prioritising what you should work on and in what order is an important part of delivering good products and services.
Decisions about what to prioritise should be made regularly - for example, weekly to prioritise the sprint backlog, or quarterly to organise the service roadmap. They should be based on performance analysis, user research and input from stakeholders.
The person leading the exercise should use a clear prioritisation method and involve the delivery team and stakeholders.
It’s much easier to prioritise work if you developed a good understanding of the problem you’re trying to solve during your discovery.
Prioritisation methods
There are lots of prioritisation methods. Choosing the right method will depend on the capacity of your team and what stage your product or service is at in the delivery lifecycle.
You’ll probably need to try out a few methods before deciding which one best suits the needs of the thing you’re working on.
Making sure you focus on more than just new features
As well as user stories for new features, your backlog is likely to contain other types of work, like support tickets or tasks to address technical debt.
It’s important to prioritise more than just work on new features. You could use something like a prioritisation quadrant to make sure you’re prioritising enough different types of work.
Building consensus within your team
It’s important to involve the rest of your team in prioritisation decisions when you can. They’ll find it easier to challenge decisions if they understand the process you use.
The MoSCoW method is useful if you’re trying to build consensus within your team. It involves breaking down the items in your backlog and roadmap into:
- ‘must haves’ - essential things that your product cannot function without
- ‘should haves’ - things that can greatly improve the product, but are not crucial to making it function
- ‘could haves’ - things that can improve the service, but will not have too negative an impact if left out at this stage
- ‘will not haves’ - low priority things that the team has agreed not to do
Prioritising tasks during the different development phases
What you consider high priority should change as your service develops.
For example, during the beta phase you’ll be able to prioritise improvements as you test and iterate the service.
During the live phase, users will be using your service so you’ll need to prioritise support work alongside continuous improvements.
- Last update:
-
Updated and expanded section about prioritisation methods.
-
Guidance first published