Agile delivery

How the discovery phase works

Give feedback about this page

From:
Agile delivery community

Before you commit to building a service, you need to understand the problem that needs to be solved.

That means learning about:

  • your users and what they’re trying to achieve
  • any constraints you’d face making changes to how the service is run - for example because of technology or legislation
  • the underlying policy intent you’ve been set up to address - this is the thing that government wants to change or make happen
  • opportunities to improve things - by sharing data with other teams, for example

This part of your project is called the discovery phase.

What you learn during discovery should help you work out whether you want to move forward to the alpha phase. Running an alpha means you’ve decided that the benefits of looking further into the problem outweigh the cost.

You should not start building your service in discovery.

Before starting discovery, check if you need spend controls approval to spend money on your service.

You can download a poster that explains what the discovery phase is for.

How long a discovery should take

There’s no set time period for a discovery, but around 4 to 8 weeks is typical. Let the purpose of your discovery dictate how long you spend on it.

If you’re working on a problem that no one’s researched before, you might need a bit longer. If it’s a problem you know a fair bit about already, you might be able to have a slightly shorter discovery.

Set a goal for your discovery

It’s useful to start by setting a clear goal for your discovery. This will help you scope your discovery appropriately and work out when it’s finished.

Define the problem

At the start of your discovery, you might be presented with a pre-defined solution or told you’re building a specific thing.

Before you start your research, you’ll need to interrogate that solution and reframe it as a problem to be solved. This will help you better understand what your team has been set up to achieve.

Break down assumptions and ask lots of questions. Reframing the problem also includes agreeing what is not part of the problem.

For example, a problem is not: “We need to build an interactive map to show people where our contact centres are”. It’s probably something like: “How can we make it easier for people to find their nearest contact centre if they need to book a face-to-face appointment?”

So start by defining the problem you’re working on. The better you define it, the better the potential solutions you’ll end up with if you move on to the alpha phase.

You should also consider quantifying the value of solving the problem you’ve been set up to address. During discovery, that means understanding how much the problem is currently costing.

What to find out in discovery

Once you’ve set a goal for your discovery and understand the problem you’re looking into, you’re ready to start research.

Focus on learning about your users and their context, the constraints that affect your problem or the wider context you’re working in - and any opportunities to improve things.

Understanding users and their context

Start by learning about your users and their context. This means understanding what the user’s trying to achieve and how they go about doing it.

When you dig into this, you’ll often find the thing you’re working on is part of a bigger process or user journey. For example, getting sponsored by an employer is only one part of coming to work in the UK.

Understanding context includes developing a picture of what that wider journey looks like - for example, by creating a low fidelity map of the services that exist in the wider problem space.

As you flesh out your map, you’ll probably notice that the problem spans across multiple departments and sometimes includes non-government organisations too.

Spend some time during discovery learning from those other teams and organisations. You should also talk to your operations colleagues, given that the user’s journey is very likely to include interactions via offline channels.

You’ll also need to learn enough about your users’ accessibility requirements to let you work out whether the problem space you’re looking at presents any particular challenges from an inclusion point of view.

Bear in mind that, in the UK, 1 in 5 people report a permanent disability. And that accessibility covers a range of other needs for people who do not have a disability.

You’ll also need to think about things like your users’ digital skills and internet access.

Understanding constraints

You’ll need to understand any constraints you’re likely to come up against if you were to move on to the alpha phase. This includes constraints due to things like:

You’ll need to work out which of these constraints are hard constraints that you will not be able to do much about. For example, primary legislation is not something that can easily be changed. But if you were to move on to alpha, you’d need to find a way of delivering a service that still works for your users.

Some constraints are soft constraints, though. For instance, if existing processes (whether in digital, call centre or paper-based teams) are preventing you from delivering the best version of your service, you’ll need to work to change those processes - do not just work around them.

Understanding constraints is helpful for two main reasons. Firstly, it helps you work out whether it’s worth continuing to alpha. If there’s a hard constraint which means you are not able to improve on the solution that’s currently available, it might be worth stopping at the end of discovery.

The second reason is that it can help you prioritise your risky assumptions if you do continue to alpha. For example, if a service will only be viable if you can change an existing process or structure, you’d want to focus on ways of doing that during your alpha.

You could also look at related or similar services, to understand the constraints they face and how they dealt with them.

Identify improvements you might be able to make

One of the benefits of understanding the user’s wider journey and who’s involved in delivering it is that you can spot things that could be improved. You could take these improvements on to later development phases.

For example, your discovery research might reveal that another part of government is already collecting the personal information you need from your users. If you decide to go ahead and build a service, reusing that data would prevent users from having to provide the same information multiple times.

You could spend part of your alpha evaluating the technical and legal challenges of reusing that data in your service.

Your research might also lead you to consider alternatives to building a service. For example, you might be able to solve the problem more effectively (or less expensively) by publishing website content, running a campaign, partnering with a non-government organisation, giving improved information to face-to-face advisors or making data or an API available to third parties.

Your service should not duplicate another government service and it should only meet user needs that it makes sense for government to meet.

How you’ll measure success

You need to consider how you’ll measure if you’ve been successful. That means you need to think about:

Sharing what you learn

Unless confidentiality issues mean you cannot, you should talk publicly about what you’re learning. You could do this by publishing blog posts or running open show and tells.

This helps people across and outside your organisation know what you’re doing and makes it easier to collaborate with the other organisations working in your problem space.

The team you need

Aim to involve a variety of disciplines, although there are some people you need to have in your team at each phase.

How you know discovery is finished

Your discovery is finished when you’ve decided whether or not you want to move on to alpha. There a couple of factors that play into this decision, including whether:

  • there’s a viable service you could build that would make it easier for users to do the thing they need to do
  • it’s cost effective to pursue the problem - this means weighing up how much it’d cost against how much of an improvement you think you could make

It’s not a failure to stop at the end of the discovery phase if your research shows that’s the best thing to do. In fact, you’ll be saving time and money that could be better spent elsewhere.

If you do decide to move on to alpha, you’ll need to make sure you:

  • understand the wider context and the other services, teams and organisations working on similar problems to you
  • are clear on how what you’re working on fits into that wider problem space
  • have a list of ideas you’d like to test at alpha and an idea of which one you’d like to test first
  • know roughly who you need in your team for alpha
  • know how you’ll measure whether you’ve been successful

You may find these guides useful:

From:
Agile delivery community
Last updated
over 3 years ago
Last update:

Added new 'How you'll measure success' section.

  1. Updated to reflect the requirements of the updated Service Standard.

  2. Added guidance on how to meet government accessibility requirements in discovery.

  3. Guidance first published