Scrum Retrospective

What is a Scrum Retrospective, which goals are pursued, which methods are there and what are the tasks of the Scrum Master?

Scrum Retrospective Definition

A Retrospective is a recap. As a term in art, it describes the examination of works by an artist and/or an epoch. In Scrum, a Retrospective is a regular event where the development team meets to illuminate the recent past – the past sprint – and thereby improve future teamwork. It is a meeting where processes, tools, skills, relationships, challenges and experiences are reflected. Feedback offers opportunities for the team as a whole as well as for each individual participant.

The development team and the Scrum Master participate in the Retrospective. There are different views on the Product Owner’s participation. The Scrum Guide defines “The 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”. This gives the Product Owner the opportunity to participate, because he belongs to the Scrum Team along with the developers and the Scrum Master. Alternatively, there can also be pure Team Retrospectives (i.e. without Scrum Master and Product Owner) or Overall Retrospectives with a representative of the team, the Scrum Master, the Product Owner and a Manager.

Goals and Advantages of the Retrospective

The Retrospective as a meeting of the Scrum team pursues different goals:

  • The improvement of the cooperation in the team and thus around the improvement of procedures and contents. It is also about the interaction between individual developers, the work of the Scrum Master and the communication with the Product Owner. The Retrospective is therefore an important part of a continuous improvement process (CIP).
  • The definition of measures, dos and don’ts, based on the jointly gained knowledge and review of the agreed measures of the past Retrospective.
  • Space and opportunity for open feedback in the team to avoid frustration and eliminate misunderstandings.

 

Scrum Retrospektive - here: Starfish Retrospective

Rules of the Scrum Retrospective

When conducting retrospectives, two simple but important rules must be observed:

  1. Vegas Rule: “What happens in Vegas, stays in Vegas.” Anything discussed in the Retrospective is reserved for the participants of the Retrospective. The meeting to improve teamwork and joint development performance is based on trust. This trust is fundamental, especially when it comes to feedback.
  2. Golden Rule: All participants treat each other with respect and esteem. It is not about assigning blame and know-it-all, it is about the team in which everyone contributes their best knowledge and skills.

 

The Scrum Retrospective in practice

Scrum Retrospective Methods

There are various methods for successfully designing Retrospectives:

  • The Starfish Retrospective helps participants to think about different degrees of collaboration and to visualise aspects accordingly in a diagram: Start Doing, More of, Less of, Keep doing, and Stop Doing.
  • The 4L Retrospective follows a similar approach, but only with 4 categories: Loved, Learned, Lacked (what did I miss?) and Longed for.
  • The 3S Retrospective has 3 categories: Start, Spice up, Stop. Similar 3-part outlines are Small Starfish or Mad, Sad, Glad or Plus, Minus, Interesting or Start, Stop, Continue.
  • In the BYOSM Retrospective, the team deals with the ideal Scrum Master that the team would wish for: Build Your Own Scrum Master. Three questions are asked: What does our perfect Scrum Master look like? What does he or she need to know about us? How can we help him or her?
  • The Weather Report offers the possibility to document moods on a flipchart in the categories sunshine, clouds, rain and thunderstorms. Likewise, Keep Your Opinion, Line Dance, Happiness Histogram and The Perfect Sprint work.
  • In Lean Coffee, topics are collected, grouped, evaluated and discussed according to the evaluation in a fixed time frame. If the topic is not finally discussed, the time can be extended.
  • When pessimising, a negatively formulated question is asked at the beginning (e.g. “What would we have done if we had missed the sprint goal?”), the answers to the questions are reversed into the opposite, in order to subsequently answer the questions “What is stopping us?” and “Why is this happening? It is similar to The Worst Thing We Can Do.
  • Make a Wish is it about dealing with the greatest challenge at work, the desire to master it, and the question “How do you know that your wish has come true?
  • In Undercover Boss the team takes a superior’s point of view and thinks about what they would change if they had been able to watch the last sprint undetected.

There are many other methods and possibilities to find out the impressions and opinions of the team members. It is up to the Scrum Master to introduce new methods on the one hand and to stick to proven techniques on the other hand. A Retrospective can also be fun despite all seriousness.

Open Questions in the Retrospective

In addition to the various methods, which are well suited for the exchange of opinions within the team, there is also the possibility of asking many individual questions in order to identify sensitivities, values, goals, procedures, etc.:

  • What can you expect from me?
  • What do I expect from the team / from you?
  • What do I want from the team / from you?
  • What do I want to do differently / better from now on?
  • What do I appreciate about you and your work?
  • What do I wish you to do better?
  • What can the team / can you be proud of?
  • What were positive / negative moments in the last sprint?
  • What was great for you / the team in the last sprint?
  • What drove you / the team / slowed you down?
  • What did you hate about the last sprint?
  • How do you like the interaction and the defined processes in the team and what would you change?
  • How do the other team members find the cooperation and the relationships among each other?
  • Where were the stumbling blocks for you / the team in the last sprint?
  • What obstructs you / the team at work?
  • What would you like to try out?
  • What went well and must be memorised so that we don’t forget?
  • How is our team perceived from the outside?
  • What did you / the team learn in the lastest sprint?
  • Which skills would you/should you like to improve?
  • How did you feel / do you think your colleagues felt?
  • Where would you have needed / been able to give more help?
  • What surprised you / the team?
  • What should we absolutely improve in the next sprint?
  • What do you want from the Scrum Master / Product Owner / Manager?
  • How do you find the use of the tools and what would you change?
  • What do you take with you from the Retrospective?
  • What do you think of the Retrospective in terms of openness, honesty and respect?

A Retrospective offers a lot of space to answer the most different questions. Two questions are important to answer at the end of a retrospective: 1. How useful was the Retrospective for you (on a scale of 1-5)? And 2: What can the moderator do better next time?

Timebox of a Retrospective

The Retrospective is a very good instrument for continuously improving performance and teamwork. It offers the opportunity to address and eliminate uncertainties and problems. The Scrum Guide recommends a timebox of 3 hours for sprints with a length of 4 weeks.

If you calculate this on a sprint of 2 weeks, you get 1.5 hours, with a sprint duration of 1 week almost 40 minutes. For short sprints, teams should consider deviating from the requirement to conduct a Retrospective at the end of a sprint. For example, teams could agree to always run the next 1.5 hour Retrospective after two one-week sprints.

It is important that the participants assess the performance of the Retrospective as positive in relation to the effort involved. Only then do the meetings make sense. And the more well-rehearsed the Scrum team is, the shorter the meetings will be.

Requirements for the Scrum Master

The Scrum Retrospective can be divided into 5 phases:

  1. Intro with greeting, clarification of goals, review of the last meeting.
  2. Collecting data, e.g. with the questions described above.
  3. Gaining insights, i.e. clarifying “Why”.
  4. Definition of measures.
  5. Retrospective of the Retrospective with the question of what should be repeated or changed at the next meeting.

The Scrum Master is responsible for this process. Usually he is the moderator and possibly also the motivator. He or she selects the methods and ensures open, trusting and honest communication. It is important to know that the Scrum Master is not a superior, he/she is an equal part of the team and therefore also tries to optimise his/her performance and the cooperation with the developers. If the Product Owner attends the meeting, the Scrum Master will ensure that he/she does not receive more speech than others. Therefore he or she needs a standing in the team and towards the Product Owner.

Want to know more about Scrum?

Then you can learn more about the Scrum Guide, the meetings in Scrum, or tips and tricks for the Backlog Refinement

Challenges for companies

Continuous improvement

Do you like to receive feedback? Do you like to give feedback? Have you ever been allowed to give feedback to colleagues? Feedback is a gift. It is a way of supporting each other, addressing problems and solving them. For this to succeed, the Vegas Rule and the Golden Rule are elementary. Adhering to these rules creates a space for self-reflection for each individual team member. This is the basis for improvements in teamwork. Methods, questions and mutual understanding help here. Ideally, there will be measures that the team addresses in the next sprint. This has to be checked at the latest for the next Scrum Retrospective. This is how measures are established, adapted or reinstated. A cycle is created, also known as continuous improvement process (CIP).

We are happy to provide you with knowledge, experience and 100% passion for your software development and requirements analysis. We help you with the collection, structuring and administration of requirements and pay attention to consistency, completeness and traceability. We support you in identifying technical correlations and consider stakeholders, goals and boundary conditions. And we plan and control your projects with these requirements on the basis of defined processes.

Find out more about software development here  »

More details and information ...