Agile Development: Sprint Retrospective


In my last two posts I’ve discussed how to carry out sprint review and sprint planning meetings. This month we’ll look at the final component of the sprint boundary process, the sprint retrospective, which is where the team analyzes its inner workings.


The sprint retrospective is an opportunity for the development team to review their performance over the previous sprint, identify strengths and weaknesses, and modify processes to increase productivity and well-being.


The retrospective should take place near the end of the iteration. It usually follows the sprint review, and can be held immediately following, but some sort of boundary should be established (take a short break, change the room, etc.) to make it clear that these are two very different meetings with very different purposes. The length of the meeting will change from sprint to sprint; budget as much time as you think you will need to fully explore team performance. If there isn’t much of substance to discuss, you can always end the meeting early and gain hero status within the team.


This is the most intimate gathering of the three we have looked at so far. No one other than the core iteration team should be present. Select stakeholders (Product Owner, department managers) may be included for some part of the meeting in order to gather feedback on specific issues, but at its core the retrospective should be limited to the people who performed the work during the iteration. Peripheral stakeholders and authority figures can dampen the effectiveness of this meeting.

Meeting Agenda

The “traditional” retrospective agenda consists of a quantitative review of team iteration metrics, followed by each team member answering the following 3 three questions to encourage dialogue:

  • What went right?
  • What went wrong?
  • What can be improved?

That’s as good a place to start as any, but your retrospective’s format should adapt to your team. Such a tightly-formatted agenda may cause some teams to fall into rote, uninspired contribution (“here, let me give you one of each and be done”), while more free-flowing conversations can fail to surface critical issues or avenues for improvement. You will want to provide enough structure to provoke meaningful exchanges, but not so much that it suppresses them. You know your team better than anyone else, so it’s up to you to identify the format that fits best.

The point of the meeting is to get your team into a comfortable critique space where everyone is comfortable sharing their thoughts on how to make the development process as efficient and effective as possible. Team members should avoid playing the blame game, but shouldn’t be afraid to point out behavior that detracts from team performance.

Of the three sprint boundary meetings, the retrospective is the hardest one to facilitate: it has the largest qualitative component, and it explores sensitive subjects like team dynamics and team member feelings. This is the meeting that will test a scrum master’s interpersonal and leadership skills the most, but it is also the one that will have the biggest impact on the development environment. When the user stories are flying fast and furious and time is at a premium, it’s easy to think of the retrospective as a luxury that the team may not be able to afford; however, it is crucial for every development team to set aside enough time to thoroughly analyze their own performance and identify the best potential avenues for meaningful and lasting change.

If you want to learn more about sprint retrospective meetings, you can check out the following resources:

I’ll be back next month to discuss how to build an agile organizational culture.

What strategies do you use to make your retrospectives fruitful? How do you encourage team members to be both forthright in their evaluations and open to criticism? How do you keep retrospectives from becoming exercises in finger-pointing and face-saving?

BIS-Sprint-Final-24-06-13-05” image By Birkenkrahe (Own work) [CC BY-SA 3.0 (], via Wikimedia Commons.