Sprint Retrospective: The what, how, and why

Of all the scrum ceremonies, this is the one that is often confused by most teams.

The sprint retrospective meeting is held after the sprint review but before the beginning of the next sprint planning meeting. By the end of the sprint retrospective meeting, the development team should have identified improvements that can be implemented in the next sprint.

What is a Sprint Retrospective Meeting?

The sprint retrospective meeting is for the development team to look back at the sprint, inspect itself, and plan for improvements that can be used for future sprints.

A good way to keep the retrospective meeting structured is to answer these questions:

1. What went well?
2. What needs improvement?
3. What did not go well in the previous sprint?

By answering the above questions, you can:

1. Inspect how the previous sprint went with respect to people, relationships, tools, and processes.
2. Identify items that went well and see where there is room for improvement.
3. Build a plan on how to implement improvements to the way development team works.

There are several other ways to run a Sprint Retrospective meeting. Read this post to see five sprint retrospective ideas with templates.

Who should attend the Sprint Retrospective Meeting?

The scrum master and the development team collaborate in the sprint retrospective meeting and try to find areas that could be improved.
The product owner is an optional attendee with no other stakeholders attending this meeting.

How long should a Sprint Retrospective Meeting last?

The sprint retrospective meeting lasts for a maximum of three hours for a one month sprint. For shorter sprints, this meeting is usually shorter.

Best practices on how to run a Sprint Retrospective Meeting

1. Take small but concrete steps

Making improvements require teams to make changes. And the thing about change is it’s always hard, especially when it’s for something good.

Look for small, incremental improvements that can be adopted by teams quickly.

For example, if your burndown chart doesn't look anywhere close to an ideal chart, you could start by identifying why that's the case. The reason almost always seems to be because the user story wasn't defined properly, wasn't broken down to subtasks. This leads to inaccurate estimation and a burndown chart that makes you anxious.

2. Keep the tone positive

When inspecting on areas to improve, it can be easy to start pointing fingers by focusing on the negatives and why they shouldn’t have come up in the first place.

Studies show positivity directly relates to better performance. By focusing on the positive aspects of what went well in the previous sprint and stating that it could be improved, you help set a positive tone for the entire meeting and avoid a possibly productive meeting turn into a rant session.

3. Acknowledge and encourage each member's contribution

During the sprint retrospective meeting take a couple of minutes to genuinely acknowledge the contributions made by each member. This is especially great to talk immediately after discussing "what could have been done better" in order to keep your team's morale up.

4. Ensure the meeting isn't dominated

Sprint Retrospective meetings are supposed to be a collaborative effort. Be sure to take in every member's opinion on what worked well and could be improved during the retrospective. If the discussion is dominated by one person, then the scrum master might have to step in and be a stronger facilitator.

5. Retrospect on your retrospect

If you ran a sprint prior to this, you most liekly had few points that you wanted to improve upon. Be sure to retrospect and see if you made progress on those points. Because at the end of the day if you aren't making progress on your ideas, then there's a good chance that your process hasn't improved much at all.