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
You might also hear these tools and techniques called ‘agile ceremonies and artefacts’.
Daily standup
The standup is a daily meeting for the team to discuss what they’re working on and whether there are any problems or dependencies they need to resolve (for example, needing help from someone else).
Standups should last no longer than 15 minutes. You should hold them at the same time every day. It’s best if you do standups 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.
Read: sprint planning by Ken Schwaber and Jeff Sutherland, the creators of Scrum
Team review (show and tell)
The team review is a regular meeting which gives team members the opportunity to demonstrate their work. It can also be called a sprint review or a show and tell.
You can invite stakeholders like directors or suppliers 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
Retrospective meetings
Retrospectives, sometimes called ‘retros’, are regular meetings where your whole team talks about what’s going well and what is not.
Teams usually hold retros at the end of an iteration (for example 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 does not 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.
End-of-phase retrospectives
Some teams run a longer retro at the end of discovery, alpha and beta. These usually include people who’ve been involved in the work from outside the team, too, like procurement or policy colleagues.
This type of retro can:
- identify what could be improved in the next phase of the project
- help people from procurement, policy or other disciplines work more effectively with service teams across the wider organisation
ONS ran an end-of-phase retro to identify which ways of working to continue and which to stop in the next phase of their data discovery project.
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 have not 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:
- 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
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:
Related guides
You may also find these guides useful:
- Last update:
-
Added information about running end-of-phase retros.
-
Guidance first published