Alpha Playbook
Note: Work in Progress
This playbook is a direct copy of the GDS agile guidelines and serves as a starting point for CPS specific implementations.
Alpha is where you try out different solutions to the problems you learnt about during discovery.
Spend alpha building prototypes and testing different ideas. And do not be afraid to challenge the way things are done at the moment: alpha is a chance to explore new approaches.
You do not have to prototype the user's entire wider journey.
You might not even want to prototype all the transaction or element you're working on: often it makes sense just to focus on the areas you think will be most challenging. This lets you do the minimum you need to test your riskiest assumptions.
Alpha services should not be available for the public to use.
With any online solutions you try out, build things that are just complex enough to let you test different ideas, not production quality code. Expect to throw away any code - and lots of the ideas you test - at the end of alpha.
By the end of alpha, you should be in a position to decide which of the ideas you've tested are worth taking forward to beta.
Alphas tend to last between 6 and 8 weeks. Which means you should book your alpha assessment within a fortnight of starting your alpha.
It's useful to think about who you'll need in your team at alpha.
It's okay to decide at the end of your discovery that you do not think it's worth running an alpha.
Focus on testing your riskiest assumptions
A crucial part of alpha is identifying your riskiest assumptions and testing them. What these are will depend on the service you're building.
For example, the problem you want to solve might be reducing loneliness and isolation. If you think an online information service might help to solve that problem, one thing you might prioritise is carrying out research to find out how the people you're trying to help receive information at the moment. If they do not use the internet at all, it's unlikely they'll use your service.
Or being able to integrate with existing technology might be a priority. The team working on Register to vote realised they'd need to build an API that integrated with the registration systems of over 400 local councils. If that had not been possible, the service would not have worked - so that's what they focused on during their alpha.
Equally, if one of your possible solutions relies on finding solutions to legislative constraints you might want to spend part of your alpha working out how feasible that is.
Work in Progress!
This site is a work in progress and any opinions contained here are intended to spark discussion within each discipline's community of practice.
Created: 2023-07-26