Contents

Overview

Agile delivery helps teams design services that are user-centred, accessible and able to improve over time. The four phases are:

  • discovery
  • alpha
  • beta
  • live

Each phase has a clear purpose. Together they form a lifecycle that helps teams deliver value early, test assumptions and adapt to change.

This is different from traditional project management. Projects often start with a fixed plan and are measured by time and budget. Agile phases focus on outcomes, user needs and continuous improvement.

Discovery: understanding users and the problem

Discovery is about learning before you build. The length of this phase depends on what you know already and what you need to learn to move forward.

In discovery, teams:

  • talk to users to understand their needs, pain points and goals
  • explore constraints such as policy, technology and budget
  • define what success looks like
  • begin a high-level roadmap and backlog of work

The aim is to understand the problem well enough to decide if you want to move to the alpha phase, and if so, what to test there.

Learn about how the discovery phase works (GOV.UK).

Alpha: prototyping and testing ideas

Alpha is about experimenting, exploring the problem and testing potential solutions.

In alpha, the team:

  • builds prototypes to test different ways of solving the problem
  • researches with a small number of users to see what does and does not work
  • learns quickly, adapts and evolves ideas based on feedback

The aim is to test different solutions to the problem identified in discovery and learn if you should take any of them to the next phase.

Learn about how the alpha phase works (GOV.UK).

Beta: building and improving

Beta is where the service starts to take shape and reach more users.

Using what they learned in alpha, in beta, the team:

  • builds a working version of the service (prototype)
  • tests it with real users in a safe, realistic way
  • iterates and improves ideas based on feedback and data
  • makes sure the service is reliable , accessible, and ready for scale

Beta can be for a small audience (private beta) or available to anyone but still being improved (public beta). 

The aim is to reduce risk and prepare the service to go live.

Learn about how the beta phase works (GOV.UK).

Live: working, iterating and constantly improving

Live is when the service is fully available for everyone to use

In live, the team:

  • tracks how the service performs through metrics and feedback
  • continues to respond to user needs and policy changes
  • makes improvements as technology and context change

Agile delivery does not end when a service goes live. Teams keep learning and adapting to maintain value for users over time.

Learn about how the live phase works (GOV.UK).

Governance and funding across each phase

Governance and funding change as the work moves through the phases. This helps teams stay accountable while keeping the flexibility to deliver value. 

In discovery, teams may:

  • secure small-scale funding to explore if there is a real problem
  • check if change is justified before committing further

In alpha, teams may:

  • get support to test different ideas and approaches
  • work towards a clear decision point on whether to proceed

In beta, teams may:

  • access larger funding and oversight as the service grows
  • focus decision on outcomes and user value, not just outputs 

In live, teams may:

  • secure ongoing funding to run and improve the service
  • monitor and adapt it continuously as needs change

Clear checkpoints at the end of each phase helps leaders make informed decisions, balancing accountability with flexibility.

Learn about governance principles for agile service delivery (GOV.UK). 

Examples in practice

Imagine a local authority aiming to improve its housing repairs service. By planning their work in agile phases, each stage builds on the last to increase confidence and reduce risk.


In discovery, the team may:

  • interview tenants
  • map the housing repairs journey
  • identify pain points, like unclear booking processes

In alpha, the team may:

  • prototype simple online booking forms
  • learn that clear time-slot choices reduce confusion

In beta, the team may:

  • build a working version of the booking system
  • relate it to a small group of tenants
  • iterate based on user feedback

In live, the team may:

  • launch the new system
  • monitor satisfaction scores and call volume
  • add new features and fix problems

Related content