Agile practices

In contrast to traditional waterfall methodologies, Agile starts with the problem, not the solution, and is comprised of several core practices.

Agile is a form of project management designed to deliver products and services that prioritise user needs above the needs of organisations or individuals.  

It forms an important part of the user centred design process. At the heart of Agile is the idea of failing fast, learning quickly, and adapting. 


The Agile roadmap documents the high-level (big picture) vision for the service and should be referred to throughout the project to support prioritisation during sprint planning. It should also guide major changes in direction as you learn more about the project. The roadmap can help stakeholders understand and stay up-to-date with your project. You should display it in a place where the whole team can easily access it. Review and revise the roadmap frequently. Detailed requirements may not be understood in the beginning nor can all changes and new requirements be predicted. 

Agile Roadmap

Kanban Wall

In Agile working, Kanban is one way to manage your project by limiting your 'work in progress' so you can constantly and consistently deliver value to users. Kanban is particularly suited where your team has a steady stream of similar work or tasks. Your Kanban Wall may be a physical wall near where your team sits where you create a visual record of your work, or a digital experience using a tool such as Trello or Airtable etc. 

On a physical wall the work is recorded on cards and/or Post-it notes, which are then moved along the wall as they pass through the production stages. 

The cards and Post-it notes have various headings, to show everything the team is working on, the stage of production it’s at, and work that’s upcoming. 

Your wall will differ depending on the service you’re building, but most teams include details of: 

  • Current work
  • Work that hasn’t started
  • Completed work 
Example Trello Kanban board


Use the wall to track 

  • Progress against goals and key performance indicators (KPIs), for live data  
  • Risks and issues 
  • Obstacles stopping you getting work done (‘blockers’) 
  • Key deadlines and dependencies 

You can also display information about: 

  • Your service vision 
  • Photos or profiles of people on your team 
  • Working arrangements such as when you have retrospectives or other meetings 

Team walls help you to 

  • Map out problems you’re exploring 
  • Manage work you’ve agreed to 
  • Share a lot of information quickly and publicly 
  • Put all your work in one place to see how it’s progressing 
  • Start conversations in your team or with others in your office about issues such as processes or blockers 
  • Encourage communication and collaboration in your team, and with the rest of the organisation 

An up-to-date wall also allows you to 

  • Have a physical focal point for the team to focus on and comment on during stand-ups  
  • Promote transparency and discussion by showing everyone in your organisation the status of your work 
  • Make decisions based on a holistic overview of your work 
  • Manage and measure workflow and spot problems 


A stand-up meeting is part of Agile methodology and is based around the theory that clear and frequent communication is the basis to working with agility. 

The good news is stand-up meetings, held daily, are usually brief – around 15 minutes. They function best with the team standing up where everyone can see the team wall so people can refer to user story cards. This helps prevent people going off topic and keeps the meeting short and on track. 

Stand-ups allow individuals to discuss progress on their part of a project. Each person should briefly discuss: 

  • What they worked on/produced yesterday 
  • Their priorities for today, and if they need help 
  • Blockers – issues that are preventing them from finishing a user story card. 
  • Stand-ups are not for solving problems. When more in-depth discussions are needed, or issues arise, arrange a huddle after the stand-up to discuss the issues in a smaller group. 

User stories 

User stories are a fundamental research tool that allow you to understand and capture your user needs. They form the basis of each sprint. A user story is generally a few sentences on a role, a need/feature and why: 

As a… (who the user is) 
I want to… (what they need from the service) 
So I can… (why they need it) 

“As an individual taxpayer I want to obtain my tax details online so that I can meet my obligations.” 
“As a tax agent, I want to see my client’s details online so that I can help them meet their obligations.” 
“As a tax officer, I want to know that the taxpayer has entered correct information so that I can correctly assess their tax return.”


Backlogs and prioritising 

Each sprint draws on a backlog of work items derived from user stories. These may include: 

  • Features 
  • Bugs 
  • Design tasks 
  • Technical tasks 
  • Administration tasks and research activities 

It’s important to regularly schedule backlog refinements to: 

  • Re-sort tasks to ensure higher priority items float to the top 
  • Write or rewrite item descriptions so they are clear to the team 
  • Agree or revisit the acceptance criteria for completion of items. 


A sprint is part of the Scrum methodology that forms the basis of Agile. Unlike Kanban, Scrum breaks work down into short, time-boxed iterations called 'sprints' with the aim of completing the 'sprint goal' at the end of each sprint, which the team determines and agrees to at the sprint planning meeting.

Sprints can vary from two weeks to one month during which an iteration of a product or service is created for release into the testing environment. A new sprint starts as soon as the previous one has ended.  

Sprints also consist of activities such as sprint planning, daily scrums, the development work review and retrospectives

During the sprint 

  • No changes are made that will impact the sprint goal 
  • Quality goals do not decrease 
  • Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned. 

Each sprint should be treated as a project with a goal accomplishing something. The team needs to know what is being built and have a flexible plan that will inform the work. 

Sprints are limited to a maximum of one month for a reason; to allow for inspection and adaptation of progress toward the final product every calendar month. This also limits risk to one calendar month of cost. 

Testing with users  

An easy way to get started is to test a small portion of tasks with users at the end of an early sprint. Focus on a single feature at a time. Be aware that while it can be tempting for team members to individually pursue different directions, this approach makes it difficult to produce a cohesive product. Working together means, at the end of the effort, there is not only something to share with the project owner but also something concrete to test with users. Anything that isn’t feasible for the team to work on should be put aside and returned to in the next sprint. This is known as the icebox. 


Retrospectives, sometimes called retros, are regular meetings where the team talks about what’s working and what isn’t, in each sprint. 

Teams usually hold retros at the end of a sprint and use them to talk about the work that took place during that time. 

The point of a retro is to fix problems and focus on the things that are working well. 

How to run a retro 

  • One person should host the retro and decide on questions for the team to talk about. 
  • If you’re hosting, pick broad questions that allow the team to set the agenda, rather than strictly setting it yourself. 
  • Retros should have an open atmosphere where every team member can speak openly and feel confident their colleagues will listen. 
  • Allow 60 to 90 minutes for the meeting and use a private space where you can stick Post-it notes to the wall. 

Retro step-by-step 

  1. The host sticks a Post-it note to the wall for each question 
  2. Each team member writes down one or more answers for each question on Post-it notes and sticks them near the relevant question 
  3. You can either discuss issues as they come up, or at the end 
  4. The host decides on actions and assigns them. 

Potential questions 

  • What worked well in the last sprint 
  • What didn’t work well in the last sprint 
  • Any blockers (issues preventing work being completed) 
  • Things the team doesn’t understand 
  • Anyone in the team other members would like to thank.

Make a list of actions 

  • Use the information from the retro to improve your work and the working environment. 
  • Make a list of actions to fix any problems the team highlighted and assign them to the team. 
  • The actions should be completed before the next retro. 


A showcase (also known as a sprint review) is an informal presentation designed to show stakeholders and project owners progress on the product or service. It's usually held at the end of a sprint to demonstrate functionality and new features.  

Think of it as an opportunity to gather feedback and allow for improvements or corrections as per Agile's inspect-and-adapt methodology.  

The idea is to keep the showcase as informal as possible - team members should feel comfortable presenting their work in a non-judgemental setting. 

The purpose of the demonstration is to map progress against that iteration’s goals. It’s a chance to incorporate feedback and ensure everyone is still in agreement regarding the roadmap and direction. 

Your showcase could include 

  • An introduction 
  • The business problem 
  • The team 
  • Snapshot of the project 
  • Current progress 
  • Vision 
  • Risks 
  • Insights from any user research sessions
  • What’s next? 




Mobile apps: iOS | Android



Mobile apps: iOS | Android


Further reading 
Agile Principles and 18F Practices


Please see the delivery manual for more

Last updated