What is Sprint Retrospective?
A Sprint Retrospective embodies one of the most important principles of an Agile mindset – continuous improvement. The concept of Sprint Retrospective is derived from the Scrum method but is useful to any kind of project regardless of their management approach. In a nutshell, and as suggested by its name, the Sprint Retrospective offers an opportunity to look back at the sprint that has just finished and, in hindsight, identify what worked well and what can be improved to detect improvements required to the ways of working of the Scrum team.
Sprint Retrospective Meeting Template
Following, it’s easily tempting to think of a Sprint Retrospective as the commonly known Lessons Learned meeting. Make no mistake, though: they are not the same. Some call it a post mortem meeting and document it as a project post mortem template.
Difference between Lessons Learned Meeting and Sprint Retrospective Meeting
There are, of course, similarities, but the Sprint Retrospective may be better understood as a Lessons Learned meeting with a purpose. In fact, the differences below apply:
- A Sprint Retrospective is not about the past but about the future: while the basis for a retrospective is the finishing sprint, the reason for analyzing that sprint is actually the future, that is, which improvements can be applied to the next upcoming sprint.
- A Sprint Retrospective is not about talk but about action: have you noticed that just after five minutes, traditional Lessons Learned meetings tend to turn into a blamestorming rather than a brainstorming? To prevent this scenario, a Sprint Retrospective is focused on actions to be completed for the next sprint – a little less conversation, a little more action.
- A Sprint Retrospective is not about everything but about the critical few. Instead of going through all potential and imaginable improvements since the project started, a Sprint Retrospective focuses only on identifying improvements from the finishing sprint. Also, given that the team's capacity is limited, improvements are prioritized by the Scrum Master so that the team can focus on the actions that matter the most for the next sprint.
- A Sprint Retrospective is not a one-off nor a continuous event but a ritual: while traditional Lessons Learned meetings tend to be held just at the end of the project or captured throughout the project in a Lessons Log, a Sprint Retrospective perceives this event as a so-looking-forward-for-it ritual, a moment of celebration and reflection that marks the end of each sprint.
Typical Lessons Learned meetings are often criticized for being a forum for lessons to be identified yet not learned since learning involves embedding and applying it to practice. In a Sprint Retrospective, the opportunity to learn and improve is real – it’s just about to start in the next sprint.
When to conduct a Sprint Retrospective?
Now that you know what a Sprint Retrospective is about, you may have guessed by now that a Sprint Retrospective happens at the end of each sprint. Yep, you are right. To be more precise is the last thing done in a sprint. Some teams may prefer to couple the Sprint Retrospective with the Sprint Review (when the sprint is assessed against objectives and a demo of features is presented); however, it can also be carried out as a separate event.
Who should attend a Sprint Retrospective?
Since the Sprint Retrospective is an opportunity for reflection and group improvement, everyone should be involved and actively contribute with their views: the scrum team, the Scrum Master, and the Product Owner. The meeting is facilitated by the Scrum Master, who ensures that the meeting is kept focused, clarifies purpose, and encourages participation. It is also the responsibility of the Scrum Master to ensure that a list of improvements is identified and prioritized as a result of the meeting.
It should be noted that there are no guests in the Sprint Retrospective meeting: everyone – including the Product Owner – is expected to actively participate with their feedback. Only by explicitly stating what one’s thoughts are about the sprint experience can the team improve its work.
Sprint Retrospective Meeting Agenda
The agenda of the sprint retrospective should address what went well during the sprint and what went wrong. If this is not the first sprint, the retrospective may begin with a discussion of the opportunities for improvement identified in the last retrospective, along with a discussion of whether or not those improvements were implemented successfully. During the meeting, team members should offer examples of processes that worked well during the sprint, emphasizing that the team should continue doing these things. Team members should also honestly point out the processes that did not work, suggesting that the team discontinues or modify these processes going forward.
Finally, team members should offer recommendations for new processes that the team should consider implementing. After the team has compiled a list of processes to continue, stop, or initiate, the ScrumMaster should facilitate creating a final list of recommendations, typically chosen by team members' votes, that the team will pursue in the next sprint. The aim is to focus on the processes rather than the outcomes; the retrospective is meant to examine how the team functioned, not what it accomplished.
Summary of Sprint Activities
Include a high-level description of the projects and which sprint this retro is about. At a high level, explain what the sprint was about and how did we plan the sprint. Briefly describe Epics, Sprints, or Story points delivered. Also, mention in a line or two how this Sprint was important to the project and what all reusable components were developed. A quick mention of the project team, including the scrum master, product owner, and the team.
What did we deliver in this Sprint?
The whole point of having a retro is that we can learn from our mistakes. This slide contains a list of items that were delivered from the sprint backlog. On this slide, discuss the various lessons learned and if any actions were discussed in the last sprint retro.
Edit the burndown chart to enter your sprint details. Enter any observations made during the sprint, examples of unplanned leave, estimates way out, etc.
What were the impediments that we faced?
List down the issues the team faced during the sprint. In the end, open it for the team for feedback. The team must get a chance to put forward their views and issues.
What went well, and What can we do better
Change the list as per your needs. It is important to go phase by phase so that team will remember what happened in those phases.
Lessons Learnt, Action Items, and Closing Comments
Add an item if you are already aware. This slide should contain a list of improvements and suggestions, also a good place to collect action items after the sprint is complete. Always open this section up for discussion so that the team can provide their feedback.
Sprint Retrospective Agenda
How to make the Sprint Retrospective effective?
- Keep it short. Ideally, the retrospective meeting should not last more than an hour, and its discussions should remain tightly focused on team goals. If individual team members have concerns or issues that they wish to discuss with ScrumMaster, those issues should be discussed in private afterward, not during the meeting.
- Engage the entire team. The ScrumMaster may facilitate the meeting, but it should be a group effort that encourages participation from all team members. No one person should drive the agenda or dominate the meeting, and each team member should feel safe in bringing up any issue that he or she feels is significant.
- Include only relevant discussion. The meeting should include a discussion of topics and processes relevant to all team members, regardless of their roles or their individual expertise. Any discussions relevant only to particular team members should be conducted in private outside the retrospective meeting.
- Keep it actionable. The meeting should include discussion only of issues over which the team has control. The agenda should focus only on processes or procedures that the team can decide to start doing, continue doing, or stop doing. The retrospective meeting is not the place for airing grievances or discussing processes that the team has no power to change.
- Ensure the learning is included in the sprint planning meeting and agile project plans.
- Document and publish the findings or meeting minutes in the end so that there a record of findings.
After an effective sprint retrospective meeting, an agile team emerges with enthusiasm for the new ideas to be implemented in the upcoming sprint. Each team member has a clear understanding of his or her role going forward. When the meeting is conducted correctly, it results in a more efficient, productive, and united team.
Sprint Retrospective Meeting PPT Template
The sample template included in this article is for the software development project. The sample template has all the key points mentioned in the agenda. The sample has examples of each of the agenda items, which can be used as a reference for your sprint retrospective. The template is meant to be used for most projects but does not necessarily fit your projects. As with all the templates, you should alter the template for best use with your project.