Scrum: How we do Sprint Retrospectives

Four weeks have passed since the last sprint planning meeting. Sprint number two has come to an end. It’s time for the sprint retrospective.

The motivation for the sprint retrospective is:

• Visualize the accomplishment – important for the team morale
• Review any impediments and discuss measures on how to avoid them in the next sprint

Here’s how we are structuring the sprint retrospecives:

The set up

The team and the product owner are allocating one hour in the meeting room. We’re looking at the wall with the task board showing the user stories, the burn down chart and the impediment backlog. This is a big paper with a post it for every impediment encountered during the sprint. We collected the impediments during the bi-weekly scrum meetings (aka daily scrum).

Visualize the achievements

First, I go through all done user stories and say a few words about every story. Time for praising the team. Developers often think “we haven’t achieved anything”. So it’s important to visualize the finished user stories.

Getting the metrics

Second, we update the burn down chart and calculate the achieved velocity ([accomplished story points] / [available man days] = [velocity]). In our case we had 74 man days available. We accomplished 38 story points. That’s a velocity of 51%. Better than last time (39%). But still quite low as we committed for 50 story points. Fail. No praise here.

Learning the lessons

Third, we do the the retrospection round: This round is split in two parts.

First, we look at the conclusions from the last sprint retrospection a month ago. Were we able to implement the lessons learned? For example: We found that the product owner Martina did not have enough time to quickly reply to the questions of the team. As a measure we gave her an assistant. Did it help? – “Yes”, the team confirms, “Martina was did have a lower response time than during the former sprint”.. Good.

Then, we go through all the impediments we collected during the daily scrums. We discuss what we can do to avoid them during the next sprint. Example: “The changes on the CSS were much more complicated than expected because our CSS is the mess”. The conclusion is: “We plan a CSS clean-up”.

Results

This meeting took about one hour. The result is:

• key metrics about the past sprint (expected velocity vs. actual velocity etc)
• A list of impediments along with the measures to avoid them during the next sprint

The team now has one day of slack time before we do our third sprint planning on Thursday.