Every agile coach and agile book worth its salt will preach the benefits of holding regular retrospectives. Most teams I work with do their best to hold them, but many claim they just don’t work. They say this important agile ceremony often turns into a finger-pointing session, or perhaps worse, a meeting where everyone celebrates a job well done while ignoring issues that are holding the team back from being even better.
Probably the single biggest cause that I see of ineffective retrospectives is the lack of clear action items to come out of the meeting. The point of a retrospective is not just to complain about things we don’t like or to congratulate ourselves on the end of a sprint. The goal is to identify opportunities to improve. Sometimes that is stopping bad practices and other times that is doing more of a good practice. Either way, in order to improve you need to make changes. In order to make changes someone has to actually do something. Action items are things for people to do.
The point of a retrospective is not just to complain about things we don’t like or to congratulate ourselves on the end of a sprint. The goal is to identify opportunities to improve.
At the end of every retrospective, make sure that there are clear activities that individuals are going to do to change the way the team operates. Sometimes these will be individual actions. Other times they may be team actions. Regardless, they need to be clearly captured as a part of the meeting.
I’ve worked with teams that despite doing a great job of creating action items nothing changed. This was usually because they wrote the action items on a white board or a set of sticky notes, agreed to them, congratulated themselves on a successful retro, and then promptly left the items in the room never to be seen again. Make sure you record the action items and store them in a place that is visible and where the team can hold themselves accountable to completing them.
A few tips for managing action items:
- Co-located teams can post the retrospective action items in a visible place within the team room. This way everyone sees them when they are in the room. If you track work on a physical Kanban board, create an action item story and put it in the backlog for the following sprint.
- Use your project management tool (e.g., Jira) to manage the action items. Just like a physical board, create a story for each action item and add it to the team backlog. In Jira, you could even create a custom issue type and track how many action items the team is working on to get a sense of how much time they are spending on improvement activities.
- If you don’t want to create stories, a Wiki that the team uses regularly can be a good alternative. There is a feature that I like in Confluence where you can create individual retrospective pages and add action items to those pages. You can then create a summary page for all the retrospectives that can show all the open action items with either the date or the sprint in which they were opened. That way it is easy to see if the team is letting items linger over time without resolving them.
- However you track the action items, the first thing a scrum master should do at a retrospective is review the open action items from previous retrospectives and discuss why they haven’t been closed.
One final note is that you can have too much of a good thing. Recently I was asked to facilitate a retrospective for a team who’s previous retrospective had resulted in over 100 action items. They even recorded them and knew where they were. Guess how many had gotten done when I came in about a month later? Basically zero. That many action items was just overwhelming.
Keep your action item list to a manageable number—no more than a handful. Even if you do identify 100 potential items, commit to only the top five or so. You don’t even need to save the others; if they remain important they will come up again at the next retrospective.
…commit to only the top five or so. You don’t even need to save the others; if they remain important they will come up again at the next retrospective.
When I held that retrospective we had a very healthy discussion but I limited the team to four high-priority action items. Within a week they had tackled at least some piece of each of them, a vast improvement over zero in a month.
Remember, retrospectives give a team the opportunity to change and improve. Clear, visible, and manageable action items identify what needs to be done to change. Retrospectives without action items mean nothing will change.
