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鈥檒l 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 测辞耻鈥檙别 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鈥檒l have your live assessment at the end of the public beta phase. Spend public beta preparing for live.

You can .

Running your service during live

You鈥檒l 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鈥檒l 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鈥檒l also need to spend time during public beta reviewing the performance metrics you set to check the data 测辞耻鈥檙别 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鈥檒l need to show that you鈥檝e 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 测辞耻鈥檙别 in live, you鈥檒l need to continue to develop your service so it forms an intuitive part of the user鈥檚 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 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鈥檒l 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鈥檒l also need to make sure:

If you鈥檝e created any new design patterns - or learned anything useful about an existing design pattern - you should share what you鈥檝e learned through the .

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鈥檚 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