The purpose of a sprint retrospective is to gain an insight into how the team performed over the last sprint. Most teams won’t do better and better every single sprint; we’re all humans and sometimes we get tired or forgetful and backslide a bit. With a good retro cadence, the team will be able to identify instances like this early on so they don’t snowball into bad habits.
This is part of a short series on scrum ceremonies and I’ve done some short pieces for each one. Here’s the complete list:
- Standups/Daily Scrum
- Backlog Grooming
- Sprint Planning
- Sprint Review
- Sprint Retrospective (you are here!)
Attendees
Because retros are all about introspection, this ceremony is more exclusive than the others and restricted to the core team. Participants in retrospectives are as follows:
- Scrum Master
- Dev
- QA
Optional:
- Product Owner
Tools
- Some kind of board to list discussion items, such as funretro.io
- Your ticketing system of choice (Jira, Trello, MS Project, etc.)
Output/Related Documentation
After each sprint retro is complete document the following somewhere accessible to the entire team:
- Example tickets
- Key discussion points
- Tag people for action items
How-to: Retrospectives
There are lots of ways to do retros to try and keep them fresh (check out funretro.io or this Trello board I made for some ideas) but the core deliverables are the same, which means the steps are similar. Below is a how-to guide on a more traditional, vanilla retrospective.
1. The Infodump
Create a space where people have the ability to dump all their thoughts on the following:
- What did we do well this sprint?
- What could we have done better?
Spend the first 5-10 minutes having everyone put down answers to these questions, as many as you can think of and duplicates are okay.
2. Organising the Infodump
The next part of a retro is grouping the team’s feedback into categories and ranking those categories from most to least important (since there may not be enough time to cover everything). Discussion is welcome here to clarify what the author meant with his/her comment; this is a collaborative process.
If you’re using funretro, each team member gets six votes by default. Team members can vote on an item by clicking the thumbs up on it, and they can choose to vote on six different items or the same item multiple times. If you’re using post-it notes, team members can vote using markers or stickers.
3. The Actual Retrospective
Starting from the top, discuss the ranked categories – why could we have done x better, or what can we carry over from y to make the next sprint go well? During this part of the retro, the Scrum Master will be recording action items to distribute after the ceremony so listen hard for actionable points while discussion is happening over the items on the retro board,
This is also a good time to focus on internal locus of control rather than external – retrospectives are introspective. For example, if an external party failed to provide some needed information, how could we have better communicated the urgency of obtaining that information? Regardless of role, everyone on the team is trying to accomplish the same thing. A successful team is one that feels in control of its own destiny, and to an extent you can build that internally as a Scrum Master.
4. Distribute the Output
This is primarily to ensure the action items from the retro are clearly communicated. Send an email, post a link, create a thread in your IM platform – whatever fits best for your team. Once you’ve distributed this list, confirm with the team that they are capable of completing their action items in a timely manner (usually within the next sprint).
About a week after the action items have been distributed, set yourself a reminder to check in on the team to see how things are going or if they need more time. Since action items don’t always turn into tickets, it’s easy to forget.
Comments are closed.