"Great Retro, everyone! I’m sure we’ll be able to focus on these 17 continual improvement items over the next two weeks while simultaneously working through our backlog!"
Sound familiar?
What’s a Retro?
For those playing along at home who may be unfamiliar with Scrum, the above is a hypothetical example (admittedly, a fairly snarky one) of the end of a Sprint Retrospective — an event in which a Scrum team looks back at the Sprint that just ended, inspects how the team is doing, and makes plans to improve going forward.
By the end of a Retro, the team should have identified some things they want to work on. This could look like:
- Get another license for a testing tool
- Improve the quality of our code reviews
- Commit code more often to reduce painful merges
- Clarify client expectations on accessibility
- Use video chat when working with offsite colleagues
- Schedule a meeting to share knowledge on design patterns
- Perform a user interview with someone from Support Persona
Blurred Focus
The example list above has 7 items, but I’ve seen teams generate lists of 20 or more potential improvements that they felt would actually help the team work better. And while the hunger to improve is great, one of the Scrum Values is Focus. As with the all the Scrum Events, going through the motions of a Retrospective without emobdying that value (and the rest), won't produce good results.
So, what happens when a team leaves the Retro with a dozen items to “focus on” during the next sprint? Unfortunately, not a whole lot. Maybe one or two of the items get some attention, but overall, the potential improvements tend to be forgotten because the team doesn’t rally around any particular item. Over time, this can lead to a lack of confidence in the Sprint Retro itself. If we never actually work on these things, why spend the time generating the list in the first place?
Some teams will vote or use another method to narrow down the list, but this can lead to some great ideas being overlooked if they never are the most important items. This is especially painful if the ones that don't make the cut are very low effort, but could still make a big impact to the team. This pattern, too, can lead to disengagement from the Retro, especially if the same person's ideas keep getting overlooked.
It was out of this desire to make more improvements, while still keeping the focus narrow for greater impact, that I developed this system for handling potential improvements generated at a Sprint Retrospective.
Narrow the Beam
I have observed that potential improvements identified at Sprint Retrospectives usually fall into one of three categories:
- Quick wins that can be done in just a few minutes
- Tasks that can be accomplished during the Sprint
- Areas of continual improvement that need special attention during the next sprint.
I call these categories Now, Sprint, and Always
Now: Quick Wins
These are items that can be crossed off in just a few minutes. They usually entail sending an email, filling out a request form, or even tweaking a development tool. My rule of thumb is that if it can be done before the end of the Retrospective (or in 10 minutes just after we adjourn), we call it a Now item and just do it right then and there.
The key to this group is getting it out of the way. If it’s already done by the start of the next Sprint, there’s no cognitive load in remembering to do it, and therefore no detriment to the team’s focus during the Sprint.
Sprint: Tasks to Be Accomplished Next Sprint
Action items in this cateogory are things that will take some work to accomplish greater than the 10 minutes required for the previous category, but are also discrete pieces of work that will be called “Done” during the Sprint. This could include setting up a repository for shared information, eliminating a dependency on an outside group, or chasing down the answer to a complex question.
The key to this group is putting it in the Sprint Backlog. This is work to be done during the Sprint to improve the effectiveness of the team. These will need to be balanced with the work required to achieve the Sprint Goal and deliver value to the Stakeholders. This mix will be different for every team, but my rule of thumb is usually to limit these to 1-3 items, depending on the size of the team, the scale of the items, and potential improvement they can yield.
Always: Continual Improvement Themes
The final category is for things the team wants to work on, but would never really call “Done”. These are higher-level, continual improvement areas that we always want to be doing as a team, but deserve some special focus during the upcoming Sprint. In the example list above, the items “Improve the quality of our code reviews”, “Commit code more often to reduce painful merges”, and “Use video chat when working with offsite colleagues” were items that came from a real team I worked with. They felt that focusing on these continual improvement items for a sprint to set or improve good habits would be beneficial.
The keys to this group are setting limits and making it visible. Because these goals can be more ongoing and less tangible, they require extra focus and discipline. I generally encourage teams to pick only one item in this area. As a rare exception to this, I have seen two "Always" items work if they are completely disconnected from one another and therefore not competing. For example, a team at a consulting firm that was developing software for a client chose one improvement that had to do with internal team interaction and another that was a goal for how they communicated with the client. They were able to work on both effectively because of the distinct contexts involved. In most cases, however, choosing one is best for maximum focus.
If the Sprint Goal governs what the team will produce during the sprint, I like to think of improvements in this category as Sprint Themes, describing how the team will work. As such, and to make these focus areas very visible, I will typically distill the item into a few words and post it in the team’s work area and/or on the Scrum board.
One final thought on items in this group: action items from Retrospectives should always be as specific and concrete as possible. In practice, I’ve seen teams struggle with getting to specificity, especially when the issue is an ongoing item like “commit code more often”. This category can be a good place to capture these items, but don’t use it as an excuse to skip the specificity altogether. Coaching the team to make them as specific and concrete as you can will help the team work on them more effectively.
From Floodlight to Laser
While I’ve seen this system work well, there certainly are still some potential pitfalls with using this approach. If the team really has generated a dozen or more potential improvements, there will still need to be some method of paring that list down to be more manageable, whether it’s voting, combining similar items, or some other method. Too many items in any one category can bog the team down just as too many items without categorization can.
Using this method of categorization can help the team work on more improvement items without sacrificing focus, and ultimately foster that relentless hunger fo continual improvement that the most effective Scrum teams embrace.
TL;DR Summary
- Run your Retro in whatever format you choose
- Generate a list of actionable improvements
- Divide them into 3 Categories:
- Now - quick wins to be done at or immediately after Retro
- Sprint - 1-3 items that can be accomplished during the sprint
- Always - 1 continual improvement theme that needs special attention next sprint
