Imagine yourself planning to make a Sunday-special dish. Waking up early in the morning, you start by rinsing the rice and place it in the rice cooker. Later, you continue to prepare the dish. When the aroma from the dish fills the entire house, everyone seems to be ready for breakfast. Unfortunately, you forget to push the Cook button, and your rice sits there in the Warm mode. What a nightmare! A missed one-second action ruins a whole plan.

Something similar happens in Scrum, where the Sprint Retrospective takes place at the end of the Sprint. Some people tend to skip it or think that this part is not crucial in the development process – especially when your Sprint runs well. You need to know that this mindset is very dangerous for the health of a project.

According to Scrum Guide, Sprint Retrospective occurs after the Sprint Review and before the next Sprint Planning. Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. The purpose of the Sprint Retrospective is to:

• Inspect how the last Sprint went with regards to people, relationships, process, and tools 
• Identify and order the major items that went well and potential improvements 
• Create a plan for implementing improvements to the way the Scrum Team does its work.

During the Sprint Retrospective, simple questions that most Scrum Masters usually ask are what went well, what not work well, and what can be improved.

After reading the explanation above, some of you perhaps start to ask this question: “We have done a good job in this sprint, so why do we need the sprint retrospective?” The team can indeed deliver all PBI successfully in the current Sprint, which is like putting the team in a comfort zone. However, without a careful situation analysis, there might be a chance that the team loses its speed and efficiency one day. The team will then suffer a slump, assuming that the work will get done without any further performance improvements. As a result, all the well-thought-out plans to complete the project fail. If at any point a sprint does not go well, that is when the ‘blame-game’ begins. It will cause good teamwork to fall apart; consequently, we will not be able to achieve the expected targets properly in each Sprint. In the worst-case scenario, it can destroy the whole project. It sounds like a headache, right?

That is why Sprint retrospective is crucial. Be fully aware that not everyone in the team is an open individual who willingly shares their opinion or problems. Just because they are quiet, it does not mean that they cannot provide valuable and insightful feedback. Therefore, we can adjust the retro by asking them to write down their opinion anonymously during the start, stop doing, and continue sections. This method will accommodate everyone to share their problems, opinion, and suggestions without directly judging or hurting their feelings.

Once the opinions are shared, ensure that the agreed actions are well-recorded. Then on the next retro, we can spend a short amount of time to follow up on the last action point and discuss whether the previous issues in the current Sprint resolved.

For continuous improvement, Sprint backlog needs to include at least one high priority process improvement identified in the previous Retrospective meeting (the Scrum Guide, November 2017). After the Sprint Retrospective, some decided not to convert this improvement into planned action items, and it can get lost somewhere between the Sprint Retrospective and the next Sprint Planning session, then forgotten.

Thus, the Sprint Backlog should include at least one high priority process improvement decided in the previous Sprint Retrospective.

The other important thing to do during the retrospective is that we must focus on the problems that will potentially disrupt the Sprint. However, we should never forget to pay attention to their feelings and relationships. Sometimes trying to share positive actions, such as pointing out good things done by the team, will help them to boost their confidence and can improve their performance as well in general.

To summarize, the Sprint Retrospective is a critical part of our scrum framework. By running a retrospective, we practice the Agile ‘inspect and adapt’ principle. The benefits of the Sprint Retrospective are that it

• helps the team identify risks and problems at an early stage and resolve conflicts or issues,
• helps the team continue to improve by identifying ‘what could be improved’,
• assists the team share ideas, opinions, and suggestions,
• gives the arrangement of start, stop & continue,
• helps the Product Owner to keep the development process on the right track,
• helps to build teamwork and trust among the team members.

The main goal of the sprint retrospective is to continually improve the quality of the product. Remember, constant improvements will bring great team productivity.

Author:
Tari Nandari Saraswati – Analyst Programmer