2 - Alpha
After a Discovery phase we move to Alpha. In Alpha we develop a 'minimum viable product' (MVP). This needs to do just enough to be able to test our key hypotheses and/or to understand whether we can overcome key project risks, without doing so much that it's too expensive or takes too long to develop. This phase is important because sometimes projects move the more complex parts to the end of a project - such as integration between systems or discovering whether users will adopt a new technology. Developing an MVP enables us to understand how to deliver a solution and whether it will work through real-life testing before we commit further resources to the solution.
In the alpha phase you need to:
- build prototypes of your service
- test your prototypes with users
- demonstrate that the service you want to build is technically possible
What to do in Alpha
During Alpha you should look to build a Minimum Viable Product (MVP)
- MVP the least amount of work that needs to be completed to get a working testable product. (Illustrated above)
- The aim should be at the end of every sprint to have produced enough of a product increment to allow it to be tested and signed off
- The MVP should be defined at the beginning of the sprint and is its goal or objective.
- The MVP should be realistic and achievable in that sprint
Tools
The key tools during an Alpha phase will be:
- Sprint Management
- Agile planning tools (eg Kanban boards physical or virtual)
- Wireframes
- Sketches
- Front-end prototyping software (eg proto.io, Invision, Balsamiq, Heroku)
- Show & Tells
- Sprint Retrospectives
- Product roadmap
Sprint Management
The sprint is a 2-4 week period of clearly defined work that has been allocated from the product backlog and can deliver an MVP
Key components
- Clear list of work items that is created from the larger product backlog list. We use Trello to manage these lists. The item list for the sprint should not be changed once finalised during sprint planning.
- Sprint planning scrum, can be done at the end of the previous sprint or start of new sprint depending on available time. This ideally will include the PO
- Regular scrums (daily if possible but no less than 3 per week) can include the PO if required and should only last 10-15 minutes
- End of sprint scrum, wrap-up of what has been achieved and what could have been done better. (mini retrospective)
- More detail on Sprints and SCRUM’s here
Moving to the next Phase
Moving to Beta Meeting
This meeting will decide whether we proceed to beta 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 beta phase and sign off the product.
The product will need to be demoed and or tested by all at the meeting.
The meeting will consider and answer the following:
- The definition of done and whether it has been delivered?
- Is the product in a fit state to be used by customers?
- Do we want it to be used by as many people as possible or more of a controlled smaller beta testing group?
- If we do not proceed do we repeat the alpha/discovery phase or end the project?
End of phase checklist
At the end of Alpha we should have:
- Evidence of what our users need, and we can justify key features and design decisions based on this evidence
- A team with a shared understanding of what needs to be done in the next phase reporting to an empowered Product Owner with sufficient time to make in-flight decisions
- A solution architecture, including the plan for hosting, infrastructure and application support and data security
- A take-up plan and plan for what to do if the service is unavailable
- Developed a clear product roadmap which has the support of senior stakeholders
