扒哥吃瓜

There鈥檚 always a long list of things you could work on when developing a product or service. But you鈥檒l 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鈥檚 much easier to prioritise work if you developed a good understanding of the problem you鈥檙e trying to solve during your discovery.

Prioritisation methods

There are lots of . 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鈥檒l probably need to try out a few methods before deciding which one best suits the needs of the thing you鈥檙e 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鈥檚 important to prioritise more than just work on new features. You could use something like a prioritisation quadrant to make sure you鈥檙e prioritising enough different types of work.

Building consensus within your team

It鈥檚 important to involve the rest of your team in prioritisation decisions when you can. They鈥檒l find it easier to challenge decisions if they understand the process you use.

The is useful if you鈥檙e trying to build consensus within your team. It involves breaking down the items in your backlog and roadmap into:

• 鈥榤ust haves鈥� - essential things that your product cannot function without
• 鈥榮hould haves鈥� - things that can greatly improve the product, but are not crucial to making it function
• 鈥榗ould haves鈥� - things that can improve the service, but will not have too negative an impact if left out at this stage
• 鈥榳ill 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鈥檒l be able to prioritise improvements as you test and iterate the service.

During the live phase, users will be using your service so you鈥檒l need to prioritise support work alongside continuous improvements.