Phases of agile delivery
View our updated agile resource
We've launched a new resource to help you work through each phase of the agile delivery process. Switch to the Delivery Manual for our updated content.
The service design and delivery process is an agile approach with four stages: Discovery, Alpha, Beta and Live.
Discovery
Discovery is the first phase of the service design and delivery process. Doing user research during Discovery is critical to understand the problem you need to solve for your users. When you know their challenges, needs and wants, you gain insights into what aspects of the problem you will need to prioritise. Discovery usually takes between four to eight weeks.
Get ready for Discovery
Before you commit to building a service, you need to learn about:
- any technology or policy constraints you might face in designing and delivering the service
- the underlying policy intent you need to address - the thing that government wants to change or make happen
- any opportunities to improve things. For example, sharing data with other teams.
Before you start
- Build the right team with skills for the Discovery phase
- Understand user-centred design and why you need to map the end-to-end user experience
- Find stakeholders and subject matter experts
- Start your user research plan and have all the approvals for your proposed research (for example, ethical reviews and approvals)
- Understand the relevant legislation, regulations and policies that may impact your service
- Have an open space for the team to collaborate
- Understand how you will do budgeting and reporting
- Check whether you need any spend controls approval to spend money on your service.
Key steps
- Establish success metrics
- Create a prioritised list of user stories
- Develop the scope of what you're going to build
- Identify legacy issues within your organisation that may impact technical aspects
- Speak to service delivery staff and policy owners to get an understanding of the existing business process
- Investigate any services that currently meet user needs, whether government or private sector
- Decide how you will develop the service, if there's a user need for one. It's vital to establish a clear and valid need for your product or service during this phase.
- Decide how you will meet NSW Government accessibility requirements
- Determine if any policy that relates to your service might prevent you from delivering a good service to your users
- Make sure stakeholders understand the project and have provided approval
- Decide if you will be moving to Alpha and build the team you will need
- Do regular presentations or showcases to show stakeholders what you've learned
- Give the service a name
The Discovery team
- User researcher
- Product management/service owner
- Designer
- Content designer (if applicable)
- Developer (if applicable)
Moving to Alpha?
It's not uncommon to find in Discovery that it's not viable for the project to continue. This is not a bad thing as it prevents time and money being wasted. This may happen if:
- there's no user need for the service or needs are being met by another service
- technology or policy challenges will prevent you from building a service that meets the user needs
- it's not cost-effective.
Alpha
Alpha is the second phase of Agile and follows Discovery. In this stage you are ready to experiment and start building prototypes of the product you've agreed on.
Most Alpha phases take around eight weeks to complete and include three stages: inception, iteration, and conclusion.
Key steps and outcomes
In Alpha you need to:
- build prototypes of your service
- test prototypes with users
- demonstrate the service you want to build is technically possible
- use prototypes to:
- find design problems and decide how you'll solve them
- estimate how much your service will cost
- identify the biggest risks for moving to beta
- decide whether to move into the beta phase
The stages of Alpha
Inception
This is where you get the team together and set goals that meet user needs, and identify risks (design, business process, technical).
By the end of inception, you should have:
- a clear understanding about the service, what it does and who it's for
- user personas (written descriptions of the people who'll use the service)
- an understanding of what currently exists that meets the user need and how what you're creating is better
- a plan for meeting NSW Government accessibility requirements (WCAG)
- clearly defined goals and risks
- an idea of the vision for your project and what it should look like when it's complete
- a clear understanding of how the service will integrate with or move away from legacy systems
- a prioritised backlog of work for your first iteration
- a presentation (showcase) to show the team and stakeholders what you've learned and what you have developed so far.
Iteration
In the iteration phase, you build prototypes, test them, learn, improve and test again. Use this period to build and test as many prototypes as possible. This is known as an iterative process. Your first attempt at a user flow will not be the final solution. The point is to keep revisiting, improving, and testing the design.
Iteration timetable
As a team, it is good to think about:
- when you might test new prototypes
- how many people you'll test with
- when you might evaluate feedback
- when you might iterate your designs
You may even want to set up an iteration timetable like the example below.
Day 1 of sprint
- Retrospective (1 hour)
- Iteration planning (2 hours)
- Start iteration
Day 2 of sprint
- User research on previous iteration prototypes
Day 3 of sprint
- Analysis of test results
Day 5 of sprint
- Demo
Keep iterating until
- You can demonstrate your prototypes meet the user need
- You've proven you don't understand the problem enough to prototype and need to return to discovery.
Conclusion
Now you decide whether to move to Beta or end the project. Just as with Discovery phase, research findings may reveal the project should cease. This may happen if:
- user needs are already being met by another service
- it's not cost effective based on the number of people who'll use it
- there is a better, non-digital solution
- it's more efficient to adapt or develop another service
- you find a new user need during alpha and decide you need to do more research.
The Alpha team
- Product manager
- Delivery manager or scrum master
- User researchers
- Content designers
- Interaction designers
- Developer
- Technical lead
- Accessibility lead
You should also have access to:
- Performance analyst
- Technical architect
- Web operations engineer
- Quality assurance and testing skills
Beta
Beta is the third phase of Agile. It involves building a working version of the service, based on the prototypes developed in alpha, that can handle real world usage and work at scale. Beta shouldn't take more than a few months.
Here, we show you what you need to achieve during this phase.
Key steps and outcomes
- Build a team with the right capabilities for this phase
- Test the service with users
- Solve technical or process-related challenges
- Arrange SSL certificates, domain name registration, and other ICT requirements
- Release updates and improvements into the development environment
- Carry out WCAG accessibility audit and testing
- Launch a private beta followed by a public beta prototype
- Plan for ongoing user research
- Decide how to measure success based on your beta phase data
- Build a working service that can be used in full by users.
Public and private Beta
Before you can launch your service to the public, you must release it in private Beta - a version with restricted access. This allows for feedback to be gathered as the service is gradually rolled out to a wider audience.
Once you move to public Beta, anyone can use your service. After the Beta release, you need to keep iterating and improving your service before going live.
The Beta team
You will need the same team as for the Alpha stage but will also require:
- performance analysts
- web operations and developers
- designers and content designers
Live
Live is the final Agile phase where you launch your product or service to the public. But it's not the end. You must continually test and improve your product so it continues to meet user needs throughout its lifecycle.
Before you can make your service live you must ensure:
- the service meets the user needs found in Discovery, Alpha and Beta
- the service's information is secure and user data is protected
- analytics have been set up to measure success
- there is a plan to transition or integrate existing services where necessary
- the service meets NSW Government accessibility requirements (WCAG)
- you can support the service and can keep iterating and improving until it's retired.
The live team
When your service moves from Beta to live, you'll usually have met most of your user needs and have less work. However, you must still plan to have a sustainable, multidisciplinary team that can:
- finish building any planned additional features
- manage and maintain the service
- iterate and improve the service frequently based on changes in your users' needs or other circumstances such as changes to technology or government policy or programs.
This means you'll need to plan how and when you change the size of your team and the roles in it. To work out when and how to do this, you and your team should review your service's road map, release plans and product backlog.