Contact the Service Manual team if you have feedback, questions or suggestions.

Agile delivery

How the live phase works

The live phase is about supporting the service in a sustainable way, and continuing to iterate and make improvements. You’ll also:

  • continue to address any constraints you identified at beta
  • continue to develop the service and work with other organisations providing services that are part of the same journey, so that you’re iterating towards solving a whole problem for users
  • transition or integrate any existing transactions that meet a similar need to yours - making sure that what you end up with has a scope that makes sense to users

You’ll have your live assessment at the end of the public beta phase. Spend public beta preparing for live.

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

Running your service during live

You’ll need to work out how to run your service sustainably during live. This does not necessarily mean having an agile team on the service 100% of the time. Spend time during public beta working out what level of continuous improvement it makes sense to support, and who you’ll need on the team.

As in beta, improvements you make during live should be:

You should also make sure you are clear on the effects that changes will have on offline channels, or any related services - and make sure none of your changes will have a negative impact.

You’ll also need to spend time during public beta reviewing the performance metrics you set to check the data you’re collecting will tell you whether your service is performing as it should.

Meeting the standard to move into live

Before the service moves into the live phase, you’ll need to show that you’ve used the beta phase to build a service that meets the needs you identified at discovery and alpha, testing and iterating based on what you learn.

Solving a whole problem for users

Once you’re in live, you’ll need to continue to develop your service so it forms an intuitive part of the user’s wider journey.

This means continuing to work with teams responsible for related services, and continuing to address any constraints affecting how you can iterate the service.

During public beta, start putting a roadmap together for this work. Items in your roadmap should be ambitious, at the level of things like:

Providing a joined up experience across channels

Before you move into live, you’ll need to make sure the people who support your users understand the online part of the service.

This might involve things like updating call centre scripts, providing training or finding a way for operations staff to walk through or familiarise themselves with the service.

Other things to consider before you move into live

Before the service goes live, you’ll also need to make sure:

If you’ve created any new design patterns - or learned anything useful about an existing design pattern - you should share what you’ve learned through the GOV.UK Design System.

When you need to retire your service

You need to retire your service if you find out users do not need it anymore - or that so few users need it that it’s not cost effective to keep running it in its current form.

You may find these guides useful:

Last update:

Updated to match the requirements outlined in the new standard.

  1. Added guidance on how to meet government accessibility requirements in live.

  2. Added the need to continue doing user research in live.

  3. Guidance first published