In Agile project management, especially in Scrum’s method, we can find at each end of sprint the sprint retrospective. This time of discussion is crucial for the team’s project.
In order to make this retrospective really useful, and to ensure the time optimization for the development team or your product, the Scrum Master needs to ask the good questions, and let the team think about it. Discover all our advices and methodologies to realize Scrum’s sprint retrospectives useful and agile.
The questions to ask during an agile sprint retrospective
An Agile retrospective allows to focus on all the elements on the kanban board realized during the iteration, as well as on the increment created and the project progresses: what went well? What can be improved for the next iterative cycle? Exchanges between the team are essential during this meeting.
📌 It actually is one of the main principles written in the agile manifesto:
Individuals and their interaction over processes and tools.
But be aware, that doesn’t concern all interactions! The creation of value is central in this process, even inside your agile’s team. And asking strong questions at the end of a sprint permits to obtain useful answers, creating added-value!
However, what do we call a strong question? Are they some methodologies alongside the Agile’s methods to formulate questions with a wide impact? Discover our three tricks to ask questions which will make your team move forward in the next project’s iterations.
Trick #1: ask open questions during the Scrum retrospective
If you want to facilitate and encourage brainstorming in your agile’s team during the Scrum retrospective, you need to avoid closed questions. While favoring opened questions, you allow the development team, the Scrum Master and the Product Owner to gather their ideas and release their point of view without censuring them. This way, you gain in agility!
📌 An opened question is a question to which you can’t answer by yes or no.
Trick #2: at the end of the sprint, ask simple and short questions
Each question of yours should contain only one idea. Therefore, your team can focus 100% of its reflection on a defined subject, and won’t get lost on the way. Of course, there is no right answers. But while building clear questions, you are sure to obtain a targeted answer. Being Agile means, in this case, being simple!
Tricks #3: give your team time to analyze the sprint
A moment of silence isn’t a time-out, on the contrary! While letting space for silence, you will create a free area and give your team the opportunity to gather their thoughts. Exercise agility its also being flexible and give a preparation time to your agile’s team!
📌 You can count up to 10 in your mind before interviewing the members of your team.
What is the point of a sprint retrospective?
This sprint’s final step takes place every end of sprints, and lasts around three hours. It completes daily meetings! No matters the type of project you are working on (software development, traditional project management or fixed price project), this meeting occurs at the end of each sprint, and is inside the planning of each team’s member.
Why doing a retrospective at the end of an agile’s sprint?
This time of discussion between the members of your project’s team (the development team, the Scrum Master and the Product Owner) allows to take a step back on all the events that have taken place during the iteration.
📌 While studying the elements that went right and the ones that went wrong during the cycle, your team will be able to offer their own improvements axis for the next sprints. Without this event, your team won’t be able to progress.
In order to organize properly your sprint retrospective following Scrum’s methods, you need to think about a few elements before the meeting.
The goals of a retrospective in Scrum’s method
To gain in agility in your project, your sprints retrospectives should be organized and need to answer a goal clear and identify by the whole team. The overall objective is, of course, the continuous improvement of your internal processes, in order to make your development more efficient and ensure a good cohesion inside your team.
Even if your meeting possesses a general goal, it can be interesting to define a sub-objective for each one of your sprint retrospectives. This way, you can adapt your meetings to the project’s actualities, and you allow your team to change point of view between each meeting. You break the monotony and gain in efficiency!
📌 For example, a goal for your sprint retrospective can be:
- The improvement of internal processes,
- The developments deleted in between sprints,
- The improvement of communication between your team’s members,
- The update of the Definition of Done,
To engage as mush as possible your team, you need to involve them in the selection of the subject that will be treated in the next Scrum retrospective. For example, you can put a board in the common area (with 2 columns, one for what went well and the other for the improvement points). Your team can add on it sticky notes during the sprint when a question comes up. The meeting’s preparation will occur during the sprint, which is a lot of time saved! Besides, it will be more simple to generate positive changes in your agile’s team.
Gather the point of view of each Scrum member
During your sprint retrospective, it is important to take into account the point of view of each development team’s members. Because they can have a different opinion on the same subject! And each one of those opinions can give you an improvement to implement in your project’s team.
Of course, you should not hesitate to stop the people that are restraining the meeting or stopping the discussion. While gathering feedback from your team, you can decide together what will be the action to take, in order to adopt an agile mindset and improve continuously!
Identify the good elements and the possible improvements
If you want to be sure to notice results before the end of your next sprint retrospective, you can select 2 or 3 actions to implement during the following sprint: let quality predominate over quantity. Think also to define KPIs, which will allow you to measure the efficiency of the decisions taken. Finally, let your team decide how those actions should be implemented! Being responsible for an action will automatically implicate your team and create engagement.