A central principle of agile is quick feedback loops – you demonstrate something to the user as soon as possible so you can see how well it suits their needs. Retrospectives are the way we apply this to our own teams to find out what’s working and what isn’t, so a team can continuously improve.

Retrospectives

A retrospective is a meeting at the end of a sprint where your team get a chance to talk about what went well and badly in that sprint, and take some actions to improve matters. It can also cover a larger scope, eg a full project retrospective.

A retrospective takes this form:

gather data

generate insights

decide what to do

This is a chance for everyone in your team to contribute to improving process/productivity.

The facilitator

All retrospectives must be facilitated. The facilitator’s role is to give everyone a chance to talk about their concerns and give positive feedback.

At the same time, they make sure the meeting remains a structured, productive meeting and doesn’t become overly negative. Ideally, your facilitator will be someone outside of your team so your whole team can contribute, but it’s not essential.

The facilitator needs to:

plan the retrospective

make sure that everyone gets a chance to contribute

keep the retrospective on track

make sure actions are created and assigned

manage time so that it does not run over

Working agreements

You’ll find it helpful to have some working agreements for a retrospective. These can be stated if necessary, eg in the first retrospective your team has.

Working agreements could be that:

everyone contributes

no one speaks over the other (except for the facilitator)

no phones or laptops are allowed – everyone should be concentrating on the discussion

Outcomes of a retrospective

During the discussion you will uncover some successes you can celebrate, as well as some problems that you can fix or things you can improve.

Make a list of actions that will address these. Aim to have done them within the next sprint or iteration.

Some problems may take longer to fix, in which case you should try to make an action that will start the process of improving it by your next retrospective.

Actions should:

be concrete and measurable (eg ‘write 10 more unit tests for the redirector’, or ‘speak to Jamie about arranging a project retrospective’; not ‘write more tests’, or ‘we should understand the lessons learned from this project’)

have a date by which they should be completed

be assigned to a specific person (and not to ‘the team’)

not be assigned to someone who is not present

Retrospectives should follow up on the actions of previous retrospectives to make sure they’ve been completed. If they’re consistently not getting done, you may have too many.

Template

You can use this template for your retrospectives. It’s based on a team of 8 to 10 and covers a 2-week sprint. 90 minutes is a reasonable amount of time to use for this scope and amount of people.

Each of the activities is timeboxed (has a set time it will run for), and it’s your facilitator’s job to make sure that your team stick to this.

Build in about 10% ‘shuffle time’ to move between activities to make sure it doesn’t overrun.

Setting the scene: 00:00 to 00:05 (5 minutes)

Explain the scope and, if necessary, purpose. If your team don’t know each other and/or are shy, include brief introductions.

Actions from the previous retrospective: 00:05 to 00:10 (5 minutes)

Make sure they’ve been completed. If any haven’t, ask if:

they still need to be done

why haven’t they been completed – set a new deadline if necessary, but don’t keep carrying actions over

The good: 00:10 to 00:20 (10 minutes)

Give your team around 10 minutes to write down all the things that went well in the previous 2 weeks on post-it notes.

If anonymity is important to encourage free expression, collect them in and add them to the wall yourself. If not, have the team take turns adding their own post-its to the wall, possibly saying a few words about each.

Don’t allow this to develop into a discussion at this point – you just want to gather data.

Discussion: 00:20 to 00:30 (10 minutes)

Group the post-its into common themes. If there are too many to discuss in the time you have then have the team prioritise, eg by voting with stickers.

Discuss each of the main areas in turn:

what should we keep doing?

why did those things go well and what can we learn?

are there any actions we can draw out?

The bad: 00:30 to 00:45 (15 minutes)

Give the team around 15 minutes to write post-its for anything that went badly.

Discussion: 00:45 to 01:05 (20 minutes)

Again, group the post-its, prioritise if necessary, and discuss the main areas:

can we work out why these things went badly?

can we work out what we need to do to improve matters, or prevent specific things happening again?

can we draw out specific actions that someone here can take that will help?

Actions: 01:05 to 01:20 (15 minutes)

Spend some time looking at the actions identified; assign them to people present and set realistic deadlines for completion.

Total: 80 minutes with 10% shuffle time.

It’s OK to finish early if people have said what they need to. It’s not OK to overrun – if there is too much to say, have the team prioritise the top areas for discussion and/or book more time for the next retrospective.

Why we do this

Having a regular retrospective means you can:

make small improvements often, ideally before problems start to fester

identify working practices that make you more efficient, productive or at least happier

Agile development practices will help you work better, and the retrospective allows you to fine-tune the process and your environment to your needs.

Getting Value out of Agile Retrospectives – Free eBook with many exercises for facilitating retrospectives, supported with the “what” and “why” of retrospectives, the business value and benefits that they bring, and advice for introducing and improving retrospectives.