Beta This is new guidance. Complete our quick 5-question survey to help us improve it.

  1. Service manual
  2. Agile delivery
  3. Agile tools and techniques

Using agile tools and techniques can help your digital service team to:

  • self-organise and plan
  • communicate (within the team and with the rest of your organisation)
  • continuously improve the way you work
  • get support from senior responsible officers (SROs) and service managers

Meeting the Digital Service Standard

To pass point 4 (use agile methods) in your service assessments, you must show how your team is using agile tools and techniques to build and run your service.

Introducing agile tools and techniques

The rest of this guide describes some of the most common agile tools and techniques that service teams use. You can use additional agile methods if your team decides they will be useful.

You might sometimes hear these referred to as agile ceremonies and artefacts.

Daily standup

The standup is a daily meeting for the team to discuss what they’re working on right now and whether there are any problems or dependencies (eg, needing help from someone else) they need to resolve. It should last no more than 15 minutes and you should hold it at the same time every day. It’s best if you do it standing up in front of your team wall.

good and bad standups - a video presentation by Adam Maddison, Head of Agile Delivery at Government Digital Service (GDS)

See: standup meetings on Wikipedia

Sprint planning meetings

Sprint planning meetings are a feature of Scrum. You should hold them at the start of each sprint.

At a sprint planning meeting, the team decides what to work on next and how they’ll do it.

The length of the meeting will depend on how long your sprint is.

See: sprint planning by Ken Schwaber and Jeff Sutherland, the creators of Scrum

Retrospective meetings

Retrospectives, sometimes called ‘retros’, are regular meetings where your whole team talks about what’s going well and what isn’t.

Teams usually hold retros at the end of an iteration (eg a sprint) and use them to talk about the work from that period of time.

The point of a retro is to fix any problems in the team and to make sure you keep doing the things that are working.

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 member of the team can speak honestly and feel confident that 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.

A basic retro could follow these steps:

  1. The host explains the questions at the beginning and 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 to the right part of the wall.
  3. The group discusses issues as they come up, or at the end.
  4. The host decides on actions to fix any problems raised, and assigns them to members of the team.

You could choose to cover 3 or 4 of the following topics:

  • what went well in the last iteration
  • what went badly in the last iteration
  • what’s puzzling the team or what the team doesn’t understand
  • who the team wants to thank (eg other members of the team)

These topics are just examples, there are many different types of retro. You can find more in the Retrospective wiki.

If you’re hosting the retro, you should pick topics which you think will prompt useful discussions in your team, for example on transparency, team learning or your working process.

Make a list of actions

You should use the information you get from your retro to improve your work and your working environment.

Make a list of actions that you’ll carry out to fix the problems that your team highlighted and assign them to people in the team.

You should aim to get the actions done before the next retro.

Team review (show and tell)

The team review is a regular meeting which gives team members the opportunity to demonstrate their work. It may also be called a sprint review or a show and tell.

You can invite stakeholders (directors, suppliers etc) to this meeting and use it to tell them about the user stories you’ve completed or other work you’ve done.

You’ll need a screen to show your work and enough space for people to join in.

If your service is part of a larger organisation or programme you may want to open up your review to the rest of the organisation every few weeks.

This gives you the opportunity to show the most important work you’ve done, talk about what you’ve learned, explain your plans for the next few weeks and answer questions. It also gives other teams the chance to see how your work relates to theirs.

See: how a Ministry of Justice team got stakeholders involved in sprint reviews

User stories

User stories are a way for your team to briefly record the things you need to do to build the service. You can use them to prompt discussions about features when you’re ready to start work on them.

See: writing user stories

The backlog

Your team will have a product backlog where you’ll store the user stories you haven’t started work on yet in order of priority. If you’re following Scrum methodology you’ll also have a sprint backlog to store the stories the team has agreed to work on in that sprint.

See:

Team walls

Your team wall is a wall near where you sit on which you keep a visual record of your work.

The wall shows what your team has done, what they’re currently doing and the work still to do.

It helps your team to collaborate and allows other people in the organisation to see what you’re doing.

See:

Read the following guides to find out about agile ways of working: