Like every individual has the need for self-improvement and development, the productivity of our work or the products we create also needs to be continuously improved over time. That is the purpose of the Sprint Retrospective meeting – Improving the Sprint!
Overview of Sprint Retrospective
Sprint Retrospective (often referred to as Sprint Retro or Sprint Improvement) is the final event in a Sprint, aiming to increase product quality and work efficiency. In Scrum, improvement is a regular activity, not just something done when issues arise with the work or product. This is an opportunity for the Scrum team to reflect on the working process of a Sprint and identify necessary changes to achieve better results in the next Sprint.
- Required: Development Team and Scrum Master
- Optional: Product Owner (PO) and other invited guests.
For a 1-month Sprint, the maximum duration for conducting the Sprint Retrospective is 3 hours. For shorter Sprints, the improvement time will also be faster, typically around 45 minutes for a 1-week Sprint.
Three main activities of the Sprint Retrospective session
- Review the past Sprint, including factors related to individuals, communication, processes, and tools.
- List the items that went well and identify areas that can be improved.
- Plan and implement improvements for the next Sprint.
How to improve?
There are several techniques that Scrum teams use to improve Sprint. Let’s take a look at some popular techniques:
Glad, Sad, Mad technique
With the Glad, Sad, Mad technique, the opinions of team members are classified into three categories:
- Glad: Items that individuals feel have been done well and are satisfied with.
- Sad: Items that are not satisfactory and can be improved.
- Mad: Items that are causing significant obstacles and are desired to be eliminated.
Similar to Glad, Sad, Mad, the Speedboat technique aims to collect and categorize the opinions of team members. In this technique, the Wind represents factors that hinder speed, the Anchor represents risks, and the Sails represent positive aspects. Please refer to the diagram below:
Quick Question Technique: Start, Stop, and Continue
Throughout the meeting, team members have to answer questions about what they will start, stop, and continue doing in the upcoming sprint. Specifically:
- Start: Tasks or activities that team members think should be added to their work process.
- Stop: Tasks or activities that team members think are ineffective or time-wasting.
- Continue: Tasks or activities that the team wants to continue but haven’t become a habit or haven’t achieved the desired results yet.
Apart from the mentioned techniques, the Scrum team can create their own techniques as long as they serve the purpose of the Sprint Retrospective session.
#1. Lack of honesty among team members
How to solve: Create a safe environment and encourage individuals to express their opinions. Typically, the arguments during the Retrospective meeting should not be taken outside the meeting. The Scrum Master needs to ensure that everyone understands and agrees to this rule.
#2. Groupthink – Herd mentality
“Groupthink” refers to the phenomenon where individuals depend on the thoughts and actions of the entire group. For example, investors hastily buy a particular coin based on others’ actions, or a post by an influential person on social media receives unanimous agreement from the crowd. Similarly, in the Sprint Retrospective meeting, some team members may tend to agree with the majority’s opinions, even if they have different thoughts. Remember that “The majority is not always right.”
How to solve: Gather individual opinions from each team member. Each person can be asked to write down their own opinions.
#3. Boring and ineffective meetings
How to solve: Diversify the meeting format and use different techniques. Additionally, changing the meeting space can bring freshness to the participants. However, it is important to ensure that external spaces like restaurants or cafes provide an environment that fosters concentration and privacy for the team.
What’s the key to a successful Sprint Retrospective meeting?
Make small but specific adjustments
The purpose of the Sprint Retrospective is to make positive adjustments for the next Sprint. However, we may not always find the perfect solution for improvement. On the other hand, significant changes often come with obstacles that are difficult to implement overnight. Therefore, the team can start by focusing on small improvements that are easier to adapt to.
Research shows that a positive mindset plays a crucial role in improving work performance and fostering creativity. Instead of solely focusing on negative aspects, start the meeting by highlighting the positive elements that were achieved in the previous Sprint. This will help maintain a positive mindset among team members throughout the meeting.
Apply the 5 Whys technique to dig deeper into the issues
The 5 Whys technique involves asking consecutive questions, where each answer becomes the basis for the next question, until the root cause of a specific problem is identified.
Example: A delayed release of an application.
- Question 1: Why was the schedule delayed? – Because the interface design was not completed.
- Question 2: Why wasn’t the interface design completed? – Because the UI/UX Designer didn’t have enough time.
- Question 3: Why didn’t they have enough time? – Because the workload estimation was inaccurate.
- Question 4: Why was the estimation inaccurate? – Because there were numerous additional tasks.
- Question 5: Why were there numerous additional tasks? – Because the task allocation within the team was not appropriate.
By using this technique, the team gains deep insights into the problem that occurred. From there, they can come up with comprehensive solutions and avoid similar mistakes in future Sprints.
Ensure an unbiased meeting.
The Sprint Retrospective meeting is an opportunity for team members to share information along with their own perspectives and observations about the team’s work. Make sure that everyone’s opinions are expressed and acknowledged. If the meeting is dominated or influenced by someone, the Scrum Master should take actions to create conditions where all team members can voice their opinions.