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
Introducing agile tools and techniques
This guide describes some of the most common agile tools and techniques that service teams use. You can use others if your team decides they’ll be useful.
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.
See: standup meetings on Wikipedia
Sprint planning meetings
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
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 (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.
Demo (show and tell)
The demo 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.
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.
- product backlog by Ken Schwaber and Jeff Sutherland, the creators of Scrum
You may also find these guides useful: