Complete our quick 5-question survey to help us improve our content.

  1. Service manual
  2. Agile delivery
  3. How the alpha phase works

Alpha is the development phase that comes after discovery.

In the alpha phase you need to:

  • build prototypes of your service
  • test your prototypes with users
  • demonstrate that the service you want to build is technically possible

You should use your experience building prototypes in the alpha to:

  • find the problems with the design of your service and decide how you’ll solve them
  • make some estimates about how much your service will cost
  • identify the biggest risks for the beta stage, as early as possible

By the end of alpha you should know:

  • whether to move your service into the beta phase
  • what you need to build in beta if you are moving into beta

The team you need in alpha

Find out how to set up your service team at each phase.

How your team should work

Your team should work in an agile way, iterating quickly so that you can learn quickly.

Stages of a successful alpha

Each alpha will be different because the risks and goals for each service are different.

Most alphas are 8 weeks long and follow these 3 stages.

  1. Inception: getting the team together to set out goals.

  2. Iterations: build prototypes, test them, learn, change and test again.

  3. Conclusion: you move on to the beta phase or end the project.


At the inception stage, you need to complete these steps, which should take a few days.

  1. Bring the team together.

  2. Set some goals for your project.

  3. Identify the biggest risks.

Bring the team together

You can hold sessions during inception to make sure your team:

  • gets to know each other and forms a team identity
  • forms a team understanding of the business itself

You may want to introduce your team to the Digital Service Standard, if they aren’t familiar with it, and to agile ways of working.

Set goals

You and your team must work out what the goals of your alpha are.

For example, some of your goals might be:

  • creating a new digital service
  • creating a service that meets user needs
  • proving that you can serve user needs that are currently being met by the private sector, due to a government service failing

Identify the biggest risks

The reason for running an alpha is to identify all the risks to your project as early as possible.

During inception you should try to identify the biggest risks and get a better understanding of them.

Types of risk

In most government projects, the risks fall into one of the following 3 categories:

  • design
  • business process
  • technical

Design risks

Design risks are any issues that come with running a user-centred design process within an iterative model.

It can often take several attempts to get a scope for your service that’s right for the user.

You need to consider:

  • how easy is it to use
  • whether the user will get through it correctly the first time
  • what errors look like
  • how you’ll analyse the user research
  • how you’ll build prototypes quickly

Business process risks

Business process risks could include:

  • how your department will integrate your new service
  • whether your department has fraud checks - talk to your Senior Information Risk Owner (SIRO) to find out
  • whether your department is set up to handle support calls
  • how to operate the service and who’s responsible if it goes down and whether you have out-of-hours support

Technical risks

Technical risks tend to be about integrating into the existing systems, for example:

  • the type of ongoing connections that are necessary between your service and your department’s existing systems
  • any special hosting arrangements, for example high security hosting

What you need at the end of inception

Every service is different, but by the end of inception your team should have some or all of the following:

  • knowledge of the service, what it does and who it’s for
  • written descriptions of the people who’ll use the service, also called ‘user personas’
  • a good understanding of whatever currently exists to meet the user need
  • a good understanding of how to meet government accessibility requirements
  • a clear set of goals and risks
  • an idea of the vision for your project and what it should look like when it’s done
  • a clear understanding of how the service will integrate or move away from legacy systems
  • a prioritised backlog of work for your first iteration

Demonstration and retrospective

You should show what you’ve learned to the service team and to your stakeholders (the project board or senior management team).

You should also hold a retrospective meeting at the end of the inception stage.


At the alpha stage, you won’t usually be able to choose a single user journey or design. You should build and test many prototypes instead.

This allows you to quickly find out which designs offer the best user experience. Your first draft of a user flow will have problems - keep revisiting the design, research and test processes and improving them.

Learn more about doing user research in alpha.

An example iteration timetable

Day 1:

  • retrospective (1 hour)
  • iteration planning (2 hours)
  • start iteration

Day 2:

  • user research on previous iterations’ prototypes
  • analysis of test results

Day 5:

  • demo

You can deviate from this timetable but you should do the user research early in the iteration to give plenty of time to feed into the next iteration. This allows fast turnaround of user stories.

Working at this pace will result in:

  • user research in iteration 1
  • stories completed in iteration 2
  • further research on updated prototypes in iteration 3

To work in this way you need well-developed prototypes. These can have backend systems that mock out service integrations, but which contain actual working logic.

If you need to iterate faster, you can start with much lower fidelity prototypes (like paper).

This allows you to test various flows and allow much faster iteration of research and prototype development.

You should keep iterating until either:

  • you can demonstrate that you’ve met the user need with the prototypes and are ready to move on
  • you’ve proven that you don’t understand the problem enough to prototype, and you cancel the project and return to discovery

At the end of each iteration

At the end of each iteration you should do a demonstration of the service journey so far which shows what your team has learned and what you’re planning to do next.

You should avoid setting up iterations that begin on Mondays and end on Fridays, since more people are absent on these days.


Deciding the alpha phase is finished

At the end of the alpha phase, you should have:

How your prototype should look

Your alpha prototype needs to allow a complete end-to-end transaction.

You should think of it as a proof of concept and use it to check:

  • you’ve got the right solution that meets the user need
  • your approach is viable and cost-effective
  • the technologies exist to implement your plan
  • the things that won’t be easy to change and whether you can still go ahead despite these
  • you understand the needs of your users enough to be able to meet them

If not, find out more and make a new prototype.

Moving on to beta

Your team should feel confident that you aren’t proposing a project that won’t work at beta. Make sure your timelines, your scope and your vision are correct according to the money and people you’ve got for the next phase.

Once you’re confident that you want to move to beta, the delivery manager and service owner should start working on a business proposal for beta, early in the alpha stage.

Starting early on the beta program proposal means your team can keep up momentum, and gives you time to get further spend control approval.

You should hold a final demo of your alpha and make sure the project board or senior management team for your service can attend.

Use the demo to show what you’ve achieved in alpha and explain your vision for the beta phase.

You should have a final retrospective and make a backlog of epic user stories for the beta.

Find out more about user stories.

Deciding not to move on to beta

You may also use the alpha stage to decide to end your project rather than continuing into beta.

For example, you may find that:

  • the user needs for the service are already being met by another government service or the private sector
  • it costs too much to build the service based on the number of people who’ll use it
  • there’s a better non-digital solution
  • adapting or developing another service is a better solution

It’s still a successful alpha if you decide not to move on to beta because it means you won’t waste time and money.

Deciding to start a new alpha

At the end of alpha, you could also decide to start alpha or discovery again, perhaps because you want to focus on different things.

For example, you might identify a user need in discovery and alpha and then discover a different user need through further research.

You may also find these guides useful:

Published by:
Agile delivery community
Last update:

Added guidance on how to meet government accessibility requirements in alpha.

  1. Guidance first published