The next in the series is the beta phase.
The beta phase is all about taking the ideas, experiments, and user stories from the alpha phase and building a real-world product which can be tested publicly.
Depending on the scope of the service a beta phase may last from as few as a couple of sprints to many sprints. It may be possible to run a beta phase in only one phase for smaller projects, and where the discovery and alpha phases have been extremely well defined.
Key aspects of a beta phase will be:
- establish and develop technical solutions such as frameworks, hardware needs or hosting solutions.
- rapidly iterate over changes to the technical solution in the light of user feedback and measurements from KPIs.
- establish a go-live plan and team handovers.
Although the alpha phase collects initial user feedback, the beta phase must build on this. As the beta phase progresses, user feedback may become more systematised (for example moving from guerilla testing to more formal observation). But there must still be a regular cycle of user feedback at least once per sprint.
The beta phase should deliver:
- a public working prototype of the service. In many cases this could be very close to the final live system. But it should be clear that it is a beta service, and may not be fully reliable.
- metrics and measurements to monitor your KPIs as the system goes live.