a simple version of the sprint retrospective
Do the retrospective every sprint on the last day of the sprint after the sprint review
- to get all topics that occured during the sprint including the outcome of the sprint review and enable a cleanup of the sprint
- our sprints end on Monday – this way the retrospective’ action points are used directly in the sprint planning on the next Tuesday (no weekend in between to forget things and maybe loose momentum)
- every sprint – to keep the heartbeat of the sprint and the inspect & adapt cycle alive. People get easier used to it.
Not in the team room but in another location (e.g. a meeting room, outside in a park,…)
- to support shifting the focus to inspect & adapt mode – and a bit away from the daily routine
- changing locations enable to open your mind and get new impressions
- emotional discussions can be solved and stay in this location. The pictures are not connected with your daily team area
I made good experience with 1,5 hours for 2-week sprints with up to 7 team members.
After some variations – now the whole Scrum team joins:
- Developers & Testers
- Product Owner and
- Scrum Master
But it’s not an open meeting where chickens are welcome (as a difference to all other Scrum meetings)
- As it’s necessary to ensure an environment of trust to enable open minded discussions (and pressure – often indirect – arises as soon as people from different hierarchy levels get together)
We started past retrospectives without the product owner joining. This changed:
- As we discussed often topics regarding stories and sprint preparation and a direct discussion with the product owner simplifies finding solutions and getting a common understanding.
- We learned to see the scrum team including the product owner.
- Action points generated in the retrospectives are developed together and the necessity to work on it in the next sprint got obvious
- The product owners are available
Having the retrospective together with the product owner simplifies inspection and adaption and widens the scope for finding solutions.
flow of activities
- moderation cards (5-10 for every team member)
- flip chart marker (unicolor – one for every team member) + flip chart marker for the moderation (4 different colors)
- card and chart wall + pins or some free space on the ground 3m x 3m
- flip chart
- sticky tape
|Flipchart marker example||Moderation card example||Card and chart wall example|
it’s the Scrum Masters task to moderate the retrospective
Remember what happend (takes ~ 20 minutes)
Goal is to generate a common picture about the last sprint. Every team member contributes to the picture. By collecting this information hidden and writte, group dynamics don’t influence information collection that much.
It sets the ground to discuss What went well & What can be improved as the next steps.
It works this way:
- every team member tries to remember things that happend during the last sprint and collects notes on the moderation cards
- per card – 1 note (max. 1-4 words , easy readable font (size))
- note everything that seems to be relevant and comes to your mind – e.g.
- regarding your sprint progress
- challenging tasks
- interesting news, gossip, changes
- discussions among team or cross over
- after 3-5 minutes the notes will settle – it’s time for the Scrum Master to ask everyone to finish the last note
- collect and roughly group your rememberings in the team by:
- having everyone sequentially, round robin putting notes on the floor or on the chart wall. For every card – the team member says one short sentence
- Scrum Master – take care that cards don’t overlap and every card is visible (ask your team members for correction, don’t change it yourself ;-)). Don’t discard cards and don’t start discussions already.
Collect what went well (takes ~ 20 minutes)
Goal is to find (new) things that helped you to achive your sprint goal(s). It enables learning within the team, creates a common understanding of things the team should keep doing. Synced with other teams it enables learning in the organization.
It works this way:
- The Scrum Master collects the point on a flipchart with the headline What went well
- based on the collected rememberings every team member can shout out points (s)he thinks it’s worth to mention
- the Scrum Master notes the points on the flipchart and asks for some more details. The details give more background what and why a point is considered to be useful
- the Scrum Master takes care
- that the team agrees on a point (and otherwise notes down, that it’s not the opinion of the whole team)
- every team member can contribute (e.g. by proactively involving team members)
- put the flipchart pages either on the wall or on the chart wall (using sticky tape or pins). It helps too keep an overview about your retrospective achievement
Collect what to improve (takes ~ 40 minutes)
Goal is to spot things that can be done in a better way. Either in the team, across teams or outside the team to support the team’s work better. Done regularly it avoids problem accumulation and can replace too much interpretation with discussion and facts. It’s the teams atmosphere cleaner and enable common problem understanding.
Start with the topic collection:
- The Scrum Master asks the team to collect important topics to discuss (based on the collected rememberings or other topics). In the first round topic headlines are collected and not yet discussed in detail.
- Note all topics on a flipchart headlined What to improve
- The team decides in which order to discuss the topics.
- You can do this via a dot voting
- Number of topics/2 = number of dots for everyone
- Every team member distributes the dots among the topics
- One topic can get at max 2 dots by one team member
- Ensure with the team that the voting order matches the expectations of the order to discuss the topics … change order if necessary
- Sometime the order is obvious and you can skip the dot voting
and continue with discussing topics in detail – starting with the highest voted topic:
- Continue on a new flipchart with the topic headline
- collect background information to enable a common understanding in the team (e.g. by using a mindmap of free float notes on the flipchart)
- What is the problem? How to see or measure it? Who is affected?
- Who is involved – and can contribute to a solution?
- collect solution proposals
- What can be done? By whom?
- Rough estimation how long it will take?
- decide on action points in the team:
- What to do next .. e.g.
- take it as a story or task in the next sprint?
- give it as an impediment to the ScrumMaster
- put it to the backlog
- needs further investigation (when,who?)
After ~40′ you’ll have a list of action points collected. It’s time for the team to already write task cards for the action points that should be addressed in the next sprint.
Done with 1,5 hours productive and highly energetic inspect & adapt it’s time for the Scrum Master to thank everyone for the contribution and close the retrospective.
After the retrospective
- the team cleans the space 😉
- the Scrum Master sticks the action points for the next sprint to the scrum board or sprint backlog (as input for the next days sprint planning) and puts things to solve in the impediment backlog
- a documentation of the retrospective is written as a retrospective summary (including what went well and what to improve). We put this documentation to our wiki.
- In the past we took photos but today we write it down again. This enables searching the learnings and sharing it better with other teams. In addition the influence of the handwriting is gone.
- the Product Owner takes things to the product backlog if necessary
Agile Retrospectives: Making Good Teams Great (Pragmatic Programmers)
|A lot more details about working with retrospectives are described in the wonderful book Agile Retrospectives.
Read my book notes