Skip to main content


Beta Phase

Beta is the third of the delivery phases. 

Why do we need Beta?

To build the Minimum Viable Product (MVP), as identified in Alpha, ready for public release.

What happens in Beta?

Beta is the phase where the team:

  • builds a fully working product that can be tested with real users
  • writes user stories that will be developed as part of the MVP
  • resolves outstanding technical or process-related challenges
  • resolves outstanding security, legal or privacy-related challenges
  • continuously improves on the product until it is ready to go live, replacing or integrating with any existing services
  • transitions the way of working (has a greater focus on user stories as tasks and actions)
  • tests the system and accessibility
  • tests the output of each sprint with real users
  • prepares and plans for moving into Live.

How long does Beta last?

Typically, Beta takes ten weeks.

Starting Beta

Before starting Beta, re-visit Alpha to ensure there is a well-defined MVP.

It is best if the existing team from Alpha continues to work on the Beta - keeping the existing empathy, context and momentum within the team. See Building a UCD Team in the UCD Reference Library to obtain the resources required for this phase.

Expand All

A kick-off for Beta will be much more detailed than Alpha. Your team will continue performing the same team rituals, like retrospectives and planning, and you will already have a good idea of roles and responsibilities.

Duration Participation Objectives
1 day (maximum) All team members Restate what the MVP is and ensure there is a shared understanding
    Determine the overall success criteria for Beta (and the key milestones along the way)
    Determine the development approach to building the MVP, and how user stories will be worked on, reviewed and completed
    Determine what ‘good’ looks like for the MVP (e.g. accessibility, design patterns, code quality)
    Develop a rough plan for user research throughout the Beta stage, and the feedback loops from the research findings
    Determine the stakeholders involved, and how the team will share progress updates. If the technology stack is not already in place, ensure it is made a priority
    Determine what ‘done’ looks like. This will make it easier for pieces of work to be accepted by the product manager. We recommend that 'done' is when the change is reflected in the prototype.

Beta teams should take a similar approach to Alpha, working in weekly sprints, with daily stand-ups and regular retrospectives.

For more information, revisit Working in Agile.

As teams move from Alpha into Beta, they may choose to move the Kanban wall into a tool like Trello or JIRA to accommodate the number of tasks required to build the MVP.

During Alpha, a backlog of user stories would have been created. Beta will use this backlog as the basis to build upon and guide the development of the MVP.

For more information revisit Defining User Stories in the UCD Reference Library.

Finishing Beta

Expand All

Completing Beta marks the end of the 20 week process but the start of the service transformation.

At the end of Beta, your team should be confident that you meet all of the Digital Service Standard unless there is a good reason to be exempt from one.

A Kanban poster will help teams to track the activities and artefacts as they occur, demonstrating how the team is meeting the Standard.

Example of a Digital Service Standard kanban poster in use.



Digital Service Standards Kanban poster


  • Has the team completed a kick-off?
  • Has the team developed user stories and are they visible to the team?
  • Has the MVP been developed and iterated with users?
  • Has the team self-assessed against the Digital Service Standard?

Next Phase

The next phase is Live

Last updated: 26 September 2016