I released the intermediate package of my Test With Spring course. Take a look at the course >>

Unleashing the Full Potential of Sprint Retrospective Meetings

Today I was asked, how the concerns mentioned in a sprint retrospective meetings can be transferred to concrete results. I am hardly a Scrum expert, but I have got some experience working as a member of a Scrum team. Thus, I decided to explain, what kind of methods I would use for obtaining maximum benefits from retrospective meetings. Those of you, who are not familiar with Scrum, might be curious to find out, what a sprint retrospective meeting really is. Glossary of Scrum Terms, which is maintained by the Scrum Alliance, defines the sprint retrospective meeting as follows:

The sprint retrospective meeting is held at the end of every sprint after the sprint review meeting. The team and ScrumMaster meet to discuss what went well and what to improve in the next sprint. The product owner does not attend this meeting.

At best, sprint retrospective meetings are a great tool for boosting continuous improvement, which in my opinion is one of most important principles of agile software development. However, in some cases the full potential of these meetings is not met. Team members might recognize what went well and point out some improvements for the next sprint. Even minutes of the meeting is written. Unfortunately they are forgotten right after the sprint retrospective meeting ends. Some improvements might even be taken to use, but this is often a result from the actions of an enthusiastic team member. It is probable that these improvements would have been taken into use anyway.

The obvious question is, what kind of methods can be used to maximize the benefits of sprint retrospective meetings? I will give you my five point checklist in following:

  1. Ensure that everyone can speak freely. The definition given by Scrum Alliance states that product owner does not participate in retrospective meetings. In my opinion, product owner can participate in retrospective meetings, but if one decides to do so, one must understand that sprint retrospective meeting is not the place for advocating ones personal agenda. The goal of the retrospective meeting is to identify improvements for the next sprint. Some of those improvements might even be related to the actions of the product owner. If the product owner does not keep a low profile, some team members might prefer to keep their mouths shut, because they are afraid of the consequences.
  2. Do not play the blame game. Do not use your energy for trying to figure out, who is guilty of making mistakes. There are two reasons, why this is a really bad habit. First, it does not help you to find a solution for the problem in hand. Second, blaming other team members will probably have a very negative effect to the team spirit and the motivation of the team member in question. You should concentrate on finding ways to improve the “performance” of the team, not lower it.
  3. Do not allow vague statements. It is important that the team members describe their opinions as exactly as possible. Vague descriptions are not useful, because they do not identify, what the problem really is. If the team members are not able to fulfill this requirement, the ScrumMaster must ensure that the actual problem is found.
  4. Transform identified improvements to concrete action points. After the improvements have been identified, it must be ensured that the suggested improvements will be done. First step of achieving this is to create concrete action points and assign them to an appropriate team member, who is responsible of finishing the task during the next sprint. This information must also be written down to the minutes of the meeting. Also, remember to create an issue to the used issue tracking system, and assign it to the selected team member. If this is not done, the improvement will probably be forgotten, because typically team members have got a lot of other things going on during the sprint.
  5. Ensure that the action points are finished. Remember to follow up the issues created to the issue tracking system, and if necessary, encourage the team members to finish them. It is generally speaking wise to assume that the team members are motivated to solve problems, which improves the quality of their work or simply makes it easier. However, in some cases they might prefer working on tasks, which are related to the actual outcome of the sprint. In this case, they must be reminded that all issues, which are added to the sprint, must be finished before the end of the sprint.

I have now described you my five point checklist, which in my opinion will help you to make the sprint retrospective meeting more beneficial. As always, you should use your own consideration when applying these principles to practice. Every organization is different, and you should use only such methods, which works for you.

About the Author

Petri Kainulainen is passionate about software development and continuous improvement. He is specialized in software development with the Spring Framework and is the author of Spring Data book.

About Petri Kainulainen →

4 comments… add one
  • Good points. Especially the one about creating issues out of the findings to the issue tracking system. The retrospective findings should be treated as any other task or issue in the next sprint: story pointed etc.


Leave a Comment