Scrum in practice: the sprint retrospective

Being Agile is iterative in more ways than one. As well as producing a product with more functionality during each iteration the team should also get better at working together in an Agile way. Scrum uses the sprint retrospective meeting to help with this.

Occurring at the end of the sprint, usually right after the sprint review/sprint demo, this is an opportunity for the team to discuss together their successes and failures: how they measured up to the goal(s) they committed themselves to; and what they could do differently in the next iteration.

Who attends the sprint retrospective?

The whole team should attend the sprint retrospective. In Scrum that includes the ScrumMaster, Product Owner and entire Scrum team.

It’s seldom a good idea to have anyone external to the team in attendance. Team members should be free to speak candidly – this is after all an exercise with the aim of helping the team work better – and not feel constrained by the thought that anything they say is being fed back to stakeholders or management.

There have even been occasions when I’ve asked the Product Owner not to attend – but these instances are rare and restricted to specific situations where their presence will inhibit a productive retrospective. The issues which have caused this must also subsequently be made transparent.

Sprint retrospective formats

The goal of the sprint retro is to come up with specific improvements to help the team work together. The focus should therefore be on people, interactions, processes, impediments and tools rather than the work itself (though of course everything will be related to the work).

In Scrum the ScrumMaster facilitates and usually time-boxes the meeting to an hour (for a two-week sprint).

The meeting usually starts with a review of what improvements the team agreed to make at the last sprint retrospective.

Many frameworks are available for promoting feedback and discussion.

The most popular is ‘Start, Stop, Continue’, where the team identifies things it should stop doing, things it should start doing and things it should continue doing.

A slight variation on this is ‘Glad, Sad, Mad’.

The ScrumMaster might go round each member in turn collecting things to start, stop or continue (or which made team members glad, sad or mad) or get everyone to write them down at once.

Varying the format of the sprint retrospective can help to keep things fresh which is why you’ll find a constantly evolving collection of techniques online. A ScrumMaster may also select a specific retrospective format in order to address specific issues in the team.

The overarching general format remains the same though: generate data, categorise the data, decide what needs the most attention, generate insight based on the teams input (normally through conversation) and derive actions based on this.

Sprint retrospective pitfalls

Badly facilitated sprint retrospective meetings can result in a team focusing on the negative aspects of working together rather than the positive. This is obviously counter-productive so the facilitator should take all steps possible to ensure that all team members are engaged; that they recognise positive aspects of their interactions and behaviour; and that they’re working towards actionable commitments for the next sprint.

It’s crucial that achievable actions are the output from a retrospective as this is what leads to the improvements. A general discussion with no actions might help the overall feeling in the team but won’t result in incremental improvement.

Over-confidence when things are going well can lead some organisations to neglect the sprint retrospective meeting but this often leads to a very predictable downturn in productivity. If you’re not continuously improving then you’re necessarily deteriorating (you can’t stand still on a moving train) so don’t neglect an essential part of the improvement process.