Beta This is new guidance. Complete our quick 5-question survey to help us improve it.
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
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.
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
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
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:
- The host explains the questions at the beginning and sticks a post-it note to the wall for each question.
- 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.
- The group discusses issues as they come up, or at the end.
- 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.
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
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.
- creating an agile working environment for more information about tools that can help you manage your backlog
- product backlog by Ken Schwaber and Jeff Sutherland, the creators of Scrum
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.
Read the following guides to find out about agile ways of working:
- Published by:
- Agile delivery community
- Last update:
A line added about retrospectives based on feedback from the community.
Team review h2
It said "You can include stakeholders (directors, suppliers etc) in this meeting and use it to inform them which user stories haven’t been completed and why."
I've never known a show and tell to be about telling people stuff a team hasn't done. So, I've changed it to:
"You can include stakeholders (directors, suppliers etc) in this meeting and use it to tell them about the user stories you've completed or other work you've done."