Retrospective
Last updated
Was this helpful?
Last updated
Was this helpful?
We use this to capture information on how our increment of work was delivered and what we could do differently so that we can learn and improve on the next increment of delivery.
The retrospective is a ceremony that we conduct at the end of a timebox (whether it is a sprint, or a project, or a day) to reflect on what we did and explore ways to improve continuously.
This is where the team Inspects & Adapts by identifying best practices and future action items.
The Scrum Guide 2020 says:
The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.
The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.
The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.
The Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
Taken from
Lessons learned meetings often focus on problems and blame and are looked at as "another meeting". They are often held at the end of the project. The problem is that at the end of the project, no one can remember what happened at the beginning.
Lessons should include positive and negative items - when the lessons learned session is held at the end, most people will focus on the negative items as they stand out.
Instead of creating a ritual retrospective for the whole initiative performed at regular intervals, the lessons can be captured as they occur, and the knowledge can be presented in showcases so that other initiatives can learn from them in real-time.
Create the lessons learned document at the start of the initiative and add to it as part of each retro (if there is something that can benefit other initiatives or future work).
Instead of having a lessons learned session at the end of the project have regular retros that capture the lessons and present them at showcases
Example agenda and guidance
There are always certain inputs required for a ceremony and outputs that you hope to achieve.
A way to remember the inputs for a retro is through PROOF:
Past What happened during the iteration? (Events) and last Retrospective actions
Results What was achieved/not achieved during the iteration?
Obstacles What got in the way?
Outlook What still needs to be done?
Feelings How do you feel about the iteration?
The outputs are:
Set of actions with owners that you plan to put in place asap that will either address the issues faced or increase the use of good practices.
A sense of completion that the timebox has been completed and we have learned from it and made ourselves, our product, and our work better.
There are five steps to a good retro:
Set the Stage: This is the opening stage. Everybody comes together and gets ready to reflect
Gather Data: Look back on the last iteration of work and see what happened
Generate Insights: Find things that went well and things that must be improved
Decide What To Do: Find actions to take and commit to executing them
Close: Wind up and say goodbye
Taken from “Agile Retrospectives” by Esther Derby and Diana Larsen
A retrospective should be a safe place for the team to talk about how the processes are working or not. A good way to set the tone of the meeting is to start with the Prime Directive, it says:
Regardless of what we discover, we understand and truly believe
that everyone did the best job they could, given what they knew
at the time, their skills and abilities, the resources available, and the situation at hand
Taken from Project Retrospectives: A Handbook for Team Reviews, N.L. Kerth
Then review the data that you have from the timebox - if you are conducting a sprint retrospective then examples would be:
Burndown chart
Review slide decks
Velocity
Notes taken during standups
Confidence levels
Liked – things you really liked
Learned – things you have learned
Lacked – things you have seen the team doing, but consider that could be done better.
Longed for – something you desired or wished for
Now that we have some data we can perform some analysis on the items. We can group items and look for themes or areas.
This step involves creating the outputs. Some questions that you can ask are:
“Can ‘we’ achieve this?”
“What does success look like?”
“What’s the first step?”
“Who is going to own this?”
Remember that you cannot control everything within your environment, sometimes, we can only influence (see Locus of Control).
At the end, do a quick "retro on the retro" by asking:
Did we have the right people?
Were the activities useful?
Did we meet our goal for the retrospective?
Finally, remember the thank everyone for their honesty and openness, and remind those who have actions to complete them asap.
Most of all, have fun with it!
During this step, the team brainstorms the good and the not-so-good aspects of the iteration. This can be done in many different ways (see ).
Taken from
