Agile Retrospective: help your team improve sprint meetings (20 - 45 minutes)

The following retrospective follows a simple format for helping teams reflect on any of the events or meetings that routinely take place during a sprint. The following example is used to help my team reflect on Backlog Refinement.

This retro follows the typical retrospective format as set out in Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen.

Setup

1. Draw some type of scale - could be as simple as a line drawn on a whiteboard. Team members will mark on the board how they feel about backlog refinement.
2. Draw a box with two columns - one will be used to capture what the team think is currently good about backlog refinement, and the second will capture what the team think could be better
3. Draw a box with two rows - one will be used to capture the top three improvements that the team want to see, the other will capture the steps that the team need to take to make those improvements a reality
4. Get a wad of post it notes

Set the stage

1. Ask each member of the team to say just a few words about how they feel about backlog refinement. Do they enjoy it? Do they think we get the outcomes we need from it? How does it compare to things they've read about, or other teams they've worked in?
2. After each team member has said a few words, ask them to mark on the scale how they feel about Backlog Refinement, ranging from bored / hated it on the one side, through to energised / love it on the other.

This provides a nice visual of how the team feels about backlog refinement, and also ensure everyone says something in the first ten minutes of the retro. This is important, because if people say something early in the session, they are much more likely to say more later on too.

Gather the data

1. Ask each team member to fill out post in notes, capturing what they like about backlog refinement at the moment, and move them to the appropriate column on the board.
2. Ask each team member to also fill out posit notes, capturing what they think we can improve.

Generate ideas

1. Once the team have captured their thoughts, ask the team to group the post it notes into any obvious clusters. We're looking here for any post it notes that cover the same topic, or essentially say the same thing.
2. Ask the team to select the top three improvements they'd like to see made to backlog refinement. If there are any obvious clusters where multiple people have written the same the same thing, that's an immediate candidate.
3. Use post it notes in the appropriate box to capture the top three improvements that the team would like to make

Don't try to make more than three changes over the course of a sprint. The pace of change needs to be kept sustainable, and if teams try to change too much too quickly, they usually don't do any of it well. Much better to focus on a few improvements, and really nail it.

Decide what to do

1. Once the team have agreed on the top three improvements they'd like to see made to backlog refinement, ask them what steps they need to take for these to become reality.
2. It's common for teams to come up with vague suggestions initially, such as "don't follow rabbit holes" or "simplify code". Ask something like "And how would we actually do that?". Keep asking this, until you identify a concrete step that the team can take. It should be something that the team can measure at the end of the next sprint to see how they've done. Remember that team improvements coming out of retrospectives should be SMART - Specific, Measurable, Achievable, Realistic and Timebound.

Outcome

This exercise should help the team appreciate what they're already doing well, gather ideas for how they can improve, and decide on next steps. Apart from helping the team converge on improvements they'd like to see made, it can also provide an opportunity to discuss tensions.

A common tension, for example, is the level of detail to be covered in the discussion during a backlog refinement meeting. Depending on the project and domain, more or less discussion of the implementation detail might be appropriate. Team members are unlikely to be entirely in agreement about the level of detail that is appropriate, and this retrospective can be a good opportunity to explore what each team members feels about this issue, and their reasoning. Often this type of discussion, approached head on, can be more useful than the specific actionable steps that emerge from it.