As a working ScrumMaster at TimeLog, I have tried to come up with an agenda for each of meetings in a Scrum cycle. At the moment, I find the retrospective meeting the hardest to keep a good pace in order to not exceed 2 hours and make sure that the team covers the most important items each time.In this blog post, I’ll try to outline our model for getting through the retrospective in an orderly fashion.
Currently, we have been using the proposed agenda for the last dozen sprints and for now it works for us. We are also using the agenda in its raw format for doing a summary. At the moment, I simply create additional sub bullets for comments and discussions as the team goes along. We store the agenda on a SharePoint wiki and the ScrumMaster (me) creates a new wiki for each retrospective including the next retrospective meeting coming up.
- How was the sprint? (Fist-to-five-method)
- Positive stories from the sprint (from each team member)
- Looking back at decisions from last retrospective. Rollback or keep?
- What is the number one challenge this sprint or what are number one thing that is holding us back from performing better? (from each team member)
- Reflect on possible reasons for these challenge. (5-Whys-method)
- Identify possible solutions and decide on which to do in the next sprint
- Any of them requires a future backlog item due to its size?
- Discuss and vote for change requests to any Scrum artifact (from any team member)
- Ideas for discussion
- Feedback on the retrospective
Item 1 – Provides a super quick feedback from the entire team about the sprint just completed. Everyone shares their thoughts without any bias. We write down each number to calculate an average (however, for now we just store it as such without looking at the averages over time). The team member with the highest vote gives a brief explanation of why that is, and so does the lowest. Quickly everyone is one the same page and it opens everyone’s minds about the current team spirit.
Item 2 – Each team member in the team must share one positive story or leaning from the sprint. This helps setting a positive focus to kick of the retrospective (which easily focuses on all the bad stuff). I have experienced it being hard to get everyone to participate, so I have introduced tagging each story with initials and this implicitly introduces some peer pressure to participate.
Item 3 – ScrumMaster before the meeting appends any decisions or trial as sub bullets and each item is discussed again in order to determine if the effect was good or bad. If the team are holding back on an item, I introduce a simple Roman vote to get to a consensus. Currently, we don’t have a fixed procedure for keepers, but if an initiative last for more than two sprints the idea is to turn it into a rule in the Working Agreement or Definition of Done.
Item 4 – The core question for the retrospective, we need to improve, but we need to find the best spot. Each team member should present at least one challenge. The trick is to avoid going too quickly into “why” and solutions for a given challenge. Each team member should have a change to add an item or add on to an existing one. Again tagging each challenge with initials might be needed.
Item 5 – The ScrumMaster picks items from the list of challenges based on number of mentions or gut feel at this point. The number of items to go through is chosen based on time and extend. The ScrumMaster should steer the team towards finding reasons, not solutions. Keep asking “why?” is an interesting exercise for getting concrete and quantifiable reasons.
Item 6 – This item might run simultaneous with item 5 in order to tie the knots after getting to good reasons to a challenge. Each item should end up with a couple of suggested actions. The team must vote on which of the suggestions to try out in the coming sprint. Voting could be done with Roman Vote or Dot-voting. The ScrumMaster is responsible to ensure the team remembers them in the sprint.
Item 7 – A solution to a challenge might end up being a spike/research backlog item. The team and Product Owner should establish on a case-by-case basis if it needs to be prioritized with everything else or it could be pushed to any sprint as a team task (a backlog item created and prioritized by the team).
Item 8 – During the sprint each team member may add sub items to this list and state which Scrum artifact the change should be done to. Each item is taken in turn and voted to be included in an artifact.
Item 9 – During the sprint subjects might have been raised during the Daily Scrums that require more discussions and time. These are added here a head of time and taken in turn during the meeting. They could also end with backlog items, artifact elements or trials for the next sprint.
Item 10 – Slot for giving feedback to the ScrumMaster about the agenda and the retrospective meeting in general.
I would be happy to hear from other Scrum teams if they are going through other agendas in their retrospectives.
Søren Øxenhave 