Phase 5: beta

Beta phase

Beta is the fifth User Centred Design (UCD) phase and the third of the delivery phases. It builds the Minimum Viable Product (MVP), as identified in the Alpha phase, ready for public release.

Typically the Beta phase takes 10 weeks.

Why do we need the Beta phase?

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 the final Live phase.

How long does Beta last?

Typically, the Beta phase takes ten weeks.

Starting the Beta phase

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

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

The kick-off

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.

Ways of working

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.

Story mapping - user stories

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 the Beta phase

Moving into Live

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

Assessing against the Digital Service Standard

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.