Framework Agile Digital Development Framework

3 - Beta

During the Beta phase you start building the service for customers to use. The objective is to build a working version of the service based on your alpha prototypes. The version you build must be able to handle real transactions and work at scale.

What to do in Beta

During the Beta phase you need to do the following:

  • improve your service by testing it with users based on the user stories you created in the alpha phase
  • carry out regular accessibility testing
  • solve any technical or process-related challenges so that your service meets the Service Standard
  • release updates and improvements into the development environment
  • measure the effect of any changes to the Key Performance Indicators (KPIs) you established in discovery and alpha, for example if you changed KPIs because of new data

Beta Feedback and Analysis

A sustainable, reliable and effective feedback mechanism needs to be established ahead of the beta release.

It needs to be able to provide good quality analysable data.

Things to consider:

  • Is the mechanism able to get feedback from all users?
  • Is the quantity and quality of feedback adequate?
  • Can the feedback responses be analysed easily and in such a way as to answer the key questions:
  • Have you built a service that can be used by all users?
  • Does the end to end process work as intended?
  • Is the process sustainable long term?
  • Is it going to deliver the ESB’s projected?

During the beta phase you should expect

  • the backlog to grow
  • Sprints will continue during beta
  • The same rules apply as with Alpha user testing (see slide User Testing)


The key tool in the building phase will be the user stories. Each user story needs to contain acceptance criteria detailing how it should work technically and what it needs to achieve for customers. In essence, the build phase is a process of working through each user story until it is ‘done’ and then moving onto the next story. The tools which can help with this include:

  • Kanban boards (either physically or digital boards like Trello)
  • Sprint Planning
  • To successfully complete the phase, you may also find useful:
  • An updated business case
  • An Equalities Impact Assessment
  • A Privacy Impact Assessment
  • A digital take-up plan

Moving to the next Phase

Moving to Live Meeting

This meeting will decide whether we proceed to live and should include the PO and Head of Service as well as specialist such as GDPR officers if required.

It will decide if the product is capable of being launched into the live phase and sign off the product.

The meeting will also decide who will take day to day ownership of the process in its live state. (this should not be done by the Digital Team)

To go live the answers to the below all have to be YES!

  • Have you built a service that can be used by all users?
  • Does the end to end process work as intended?
  • Is the process sustainable long term?
  • Is it going to deliver the ESB’s projected?

End of phase checklist

We must have:

  • A service that works for users first time, unaided and evidence to show that it meets their needs
  • A team that can support the service, have a shared understanding of how it works and understands the remaining user stories and how to achieve them
  • Tested the service end-to-end in an environment similar to the live environment, on all common browsers and devices
  • Promoted the service
  • Started measuring the performance of the service
  • Support for those who cannot use a digital service without assistance
  • A plan for what to do if the service is unavailable
  • A completed Service Standard assessment
  • An updated, completed Privacy Impact assessment

Digital Services

The Digital Service team at Maidstone Borough Council lead on the research, design and development of user centered services for residents in Maidstone

Find out more about the team

Recent posts

TADS Get Human-Centered
Keeping residents updated about their bin collections
TADS Weeknote #2