BETA This playbook is in BETA, we think it’s good enough to be useful right now, but there are gaps that need filling – your feedback will help us to improve it.

How We Use Agile in Our Workflow

We follow the Agile methodology, which means we work flexibly and responsively. Instead of doing everything at once, we break projects into smaller parts called sprints—each sprint lasts two weeks and focuses on a specific task or goal.

We build a Minimum Viable Product (MVP)—a basic version of the product that users can try out. Their feedback helps us improve the product in the next sprint. This cycle continues until the product is fully developed.

Agile is especially useful for government services, which need to adapt quickly to changes in policy or public needs. Unlike traditional project management, which sticks to a fixed plan, Agile allows us to change direction based on:

  • User feedback
  • Stakeholder input
  • Research findings

We hold regular check-ins to review progress and make adjustments. This approach helps us:

  • Develop products faster
  • Collaborate better with users and stakeholders
  • Stay flexible and improve continuously

There are four core Agile values:

  1. Individuals and interaction over processes and tools
  2. Working software over documentation
  3. Customer collaboration over contracts
  4. Responding to change over following a plan

Key Elements of Agile Sprint Management

Sprint Planning

At the beginning of each sprint, the Service Manager, Product Owner and team meet to plan the work that will be accomplished. This involves selecting items from the product backlog, estimating the effort required, and setting a sprint goal focused on user and business needs.

Daily Stand-ups

These are short, daily meetings where team members discuss their progress, any obstacles (blockers) they are facing, and their plans for the day. This helps keep everyone on the same page and allows for quick problem-solving.

Sprint Review

At the end of the sprint, the team discuss their completed work for feedback. This ensures that the project is on track and meets the stakeholders’ needs.

Sprint Retrospective

After the sprint review, the team reflects on what went well, what did not, and how they can improve in the next sprint. This continuous improvement process is vital for maintaining high performance.

Why is Agile Sprint Management Important?

Agile sprint management is crucial because it:

  • Enhances Flexibility: By breaking down projects into smaller, manageable sprints, teams can quickly adapt to changes and new requirements.
  • Improves Collaboration: Regular meetings and reviews foster better communication and teamwork.
  • Increases Productivity: Focused sprints help teams concentrate on specific tasks, reducing distractions and improving efficiency.
  • Ensures Quality: Continuous feedback and iterative development help catch and fix issues early, leading to higher-quality outcomes.

Analogies to Understand Agile Sprint Management

  1. Cooking a Multi-Course Meal: Imagine you are cooking a multi-course meal. Instead of preparing everything at once, you focus on one dish at a time. You start with the appetizer, gather all the ingredients, cook it, and then taste it to see if it needs any adjustments. Once the appetizer is perfect, you move on to the main course, and so on. This way, you make sure each dish is of high quality and can make changes as needed based on feedback.
  2. Building a House: Think of building a house. Instead of trying to construct the entire house in one go, you break it down into smaller tasks. First, you lay the foundation, then build the walls, install the roof, and so on. After each phase, you inspect the work to make sure it is done correctly and make any necessary adjustments. This approach helps you manage the project more effectively and ensures a sturdy, well-built house.

Project Phases

We use the following steps as a pathway or guide to running a project. It’s important to remember that with agile, things are not always linear; steps can be repeated if our findings show something is not fitting right or stopped if it is no longer viable. This is a general overview; you can read a more detailed guide on website creation.

Initiation

We start by getting everyone on the same page. This includes:

  • Why the project matters
  • What we want to achieve
  • Who’s involved
  • A rough timeline
  • What’s most important

Concept

We look at the original idea and why it’s needed. We also confirm who the key people are.

Discovery

We explore the idea in more detail through workshops and research.
We talk with service teams and stakeholders to understand:

  • What users and the business need
  • Any risks or challenges
  • How it might affect other services
  • What the timeline could look like
    We might also outline a basic version of the product (called a Minimum Viable Product or MVP).

Inception

The Product Owner picks a team with the right skills and gives them the tools they need to start designing the content, creating mock-ups and prototypes.

We keep checking in with stakeholders and users to make sure we’re building the right thing.

Construction

We build the first working version of the product (the MVP) in a test environment.
Additional features and tweaks can be added in later iterations based on peer review and user feedback.

Iteration

We test and review the product with users and technical teams.
Feedback is shared with stakeholders.

Release

The product is launched. We do final testing, put it live, and check how it’s working.

Maintenance

The product is monitored and updated based on user feedback. The team will provide ongoing support to keep the system running smoothly and resolve any new bugs. Over time, new iterations take place to refresh the existing product with upgrades and additional features.

Last reviewed: August 19, 2025 by Sophie

Next review due: February 19, 2026

Back to top