How to organize a good Sprint Retrospective session

One major skill every Scrum Master should build on is COMMUNICATION, you should be able to communicate the goal of the product to your team, as well also establishing a good communication system to get feedback from them. A good communication system helps in organizing a great sprint retrospective session. Scrum is about inspection, and a good way to achieve that is through a continuous Sprint Retro.

The primary aim of a sprint retrospective is to get feedback from the team working on a product. The essence is to understand the challenges the product might be facing during development, and also to work around a better solution for the product building moving forward. By the end of a sprint retro, the scrum team should have identified some improvements and pitfalls that they can work on moving ahead on the projects.

A Sprint Retrospective is a review meeting that takes place at the end of a sprint to help develop transparency, it also helps in highlighting team success, and the challenges they faced during a sprint, as well as creating a better plan to help the scrum team be more productive moving forward.

Who should participate?

Since this exercise helps in coming up with a development plan, the entire team should therefore participate, also everyone has to be transparent during the sprint retro.

How long should it last?

The length of a sprint retro should ideally be dependent on the length of the sprint itself, but it could be longer if there were a lot of pitfalls encountered during the sprint. A maximum of 2–3 hours for a month’s sprint, for a shorter sprint, it should be a maximum of 30–45 minutes. When preparing and setting up timing and questions as a scrum master, be careful not to bore the scrum team during the retro.

When is it held?

For me, I would say anytime is a good time to have a sprint retro, if the scrum master needs to gather the team so they can improve on certain things immediately, then by all means that should happen. Ideally, a sprint retrospective is held at the end of a sprint after the sprint review.

STAGES OF A SPRINT RETROSPECTIVE

There are five stages in a sprint retro according to Esther Derby, and Diana Larsen in their book, Agile Retrospective. I will be listing out these five stages; they serve as an important guide to anyone who wants to carry out a productive sprint retro.

1. Set the stage

Set out the agenda and timing for the retro. Take out time to plan out how it should go, you want to carry every member of the team along when having these conversations, which is why you must have a plan in motion.

As the scrum master, you want to ensure that you have a productive meeting, so making adequate preparation before you start the conversation is essential. I remember not doing too well in my first sprint retrospective because I did not set the stage well, the mistake I made was thinking I could just browse through random questions on the internet without fitting them properly into the Product my company was building, the engineers were lost at some of my questions, they kept telling me that they did not understand my point. I also made it look like a question-and-answer session rather than a discussion.

In a sprint retro, you create values that everyone should follow, or you can reiterate previous values in a situation where you have one. Time management is a very important aspect here; I remember having close to 20 questions in my first sprint retro, I am very sure the development team could not wait for the whole thing to be over.

2. Gather data

Be careful not to gather the wrong data, if you do, the retro will be a flop, I learned from this mistake because I did that in my first retro, it was my first time and I did excellently well in making mistakes in such a way that I can never surpass.

In gathering data, ensure everyone makes valid contributions during these sessions. Organize it in such a way that everyone can speak up, listen attentively to what each person has to say, rather than having a question-and-answer session. In gathering data ask questions like:

a. How was the previous sprint?

b. What are the challenges you encountered working on your tasks?

c. What are the pitfalls you foresee on this product moving ahead?

3. Generate insights

After gathering data, open an interaction where you can get more insights on challenges, at this point you should talk to the team about their performance and how they can improve on that moving forward.

4. Decide what to do

The essence of a sprint retrospective is for the team to improve on their performance. At this stage you make decisions on what and what needs to be done to improve performance in the next sprint, for example, I was working on a product that seemed very demanding and due to our tight schedule we run two weeks sprint, the time was not enough for the developers, the sprint could be delayed for 2 or 3 extra days before completion, I realized the major delay was from the frontend developer. After looking at the situation, the issue reached was for the frontend developer to pick up another task he could work on if the endpoint he was expecting from the backend developer was not forthcoming in time, rather than do nothing and be stuck in a position.

5. Close the retrospective

Reiterate your decision, and ensure that everyone is clear on whatever decision you must have come up with, thank them for their participation and close the sprint retrospective.