Scrum Retrospective 4: Decide What To Do

This is the fourth post of my blog post series about the five phases of a Scrum Retrospective. In this post I cover Phase 4 - Decide What To Do.

If you haven't read the previous posts in this series you can start with Phase 1 - Setting the Stage

These five stages are presented in the book Agile Retrospectives - Making Good Teams Great by Esther Derby and Diana Larsen. They are:

1. Set the Stage
2. Gather Data
3. Generate Insights
4. Decide What to Do
5. Close the Retrospective

I use this five-step approach as a guideline in each Retrospective meeting, which I lead as a Scrum Master.

We have covered the first 3 phases. After Phase 1 - Setting The Stage, we spend a considerable amount of time in Phase 2 - Gather Data to identify the most crucial problems of the team.
Then I covered Phase 3 - Generate Insights in my previous post. At the end of that phase, we had a list of possible root causes and potential solutions to a problem.

Now, let's go on with Phase 4 and decide what we are going to do about the problem.

The goal of this phase is to create action items to improve in the next iterations.

You identified a list of possible root causes of the problem and potential solutions. Now you want to decide what you want to do differently in the next Sprint.

Therefore you create a list of action items what you exactly want to do differently.

When creating action items there are a couple of things you want to keep in mind:

1. Make action items actionable
2. Make action items small
3. Don't pick too many action items
4. Make action items visible

Let's look at each bullet point of this list a bit more closely.

1) Make Action Items Actionable

You want to phrase your action item in a way that it is completely clear what needs to be done. Be as specific as possible. It shouldn't require a discussion with the team to determine whether an action item can be considered to be completed or not.

An example for a bad action item is "improve team collaboration." Phrasing it like this does not tell you what you need to do exactly. It leaves a lot of room for interpretation.

A better example would be "Pair programming on Monday and Wednesday from 10:00 to 12:00." This tells you exactly what you need to do and when you need to do it. And only if you have really worked together in pairs for those two hours it is clear to everyone on the team that you can mark the action item as completed.

2) Make Action Items Small

You want to make action items small enough so that they don't have an impact on the amount of planned work for the upcoming Sprint. At this point in the Retrospective, you don't want to commit to working on a big action item.

Planning and prioritizing is done in Sprint Planning, but not in the Retrospective meeting.

If the action item requires a couple of days of effort to be completed, then it is definitely too big. For instance, "Implementing 2-factor authentication for the web application" is too big for an action item of a Retrospective.

If your team is sure that they want to work on that with high priority, then the action item might be "Create a user story for 2-factor authentication and put it on top of the backlog."

Big action items contain the risk that they are not worked on or cannot be finished in the Sprint. Or something else might be considered more important in the next Sprint planning. If that happens regularly, then your whole Retrospective meeting has become just a meeting where you commit to things you wish to improve instead of actually improving them.

Having small action items makes sure that they will be completed. Then your team will be consistent in making sure that action items are always finished.

3) Don't Pick Too Many Action Items

If you have too many action items it is likely that the team will forget about some of them. It is easy to remember 3 things, but it is a lot more difficult to remember 7 or even more things.

Therefore, I make sure that my team creates a maximum of 3 action items per Retrospective so we can keep the focus on the few most important items.

4) Make Action Items Visible

Another method, which proved to work very well, is to make action items visible to the team.

You place the stickies with the action items at a place where the team can see them. Usually, I put them on the physical Scrum board, which is in the team area. Additionally, you can use some "screaming" colors, like pink or orange, so that they stand out on the board.

Then, a couple of days after the Retrospective meeting, when you see that an action item is not marked as done yet, you can ask the team during Standup about the status. You make the action item "visible" in their mind by pointing it out during the Standup.

So, by making the action items visible to the team in different ways, you can do your best to make sure they will be worked on and completed until the end of the Sprint.

Try-Measure-Learn Loop

There is one more important thin, which you should keep in mind when creating your action items: make it clear to the team that you are dealing with complex problems here.

Each problem does not have just one root cause and exactly one solution. There might be a combination of circumstances, which lead to your specific problem and therefore, there are also multiple things you need to do in order to solve it.

So there is not one obvious thing what you can do to fix the problem. Make it clear to the team that Scrum is an empirical approach — you are working with a try-measure-learn loop.

If you have identified a possible solution, you cannot be sure whether this solution might really work. But you can decide to give it a try for a couple of Sprints and measure its outcome.

Then based on what you measure you can learn that this is a good solution and you keep it. Or you might find bad results and decide to drop that solution because it didn't help to fix the problem.

If this is not clear to people, I noticed that some respond very negatively to certain action items.

For instance, imagine you have a big issue and you have an action item to tackle that problem. Then, one simple action item is often just a drop in the ocean. This means that even if it is completed it will not have a big impact.

Therefore, it is not surprising that some people will react like, "That's not gonna help anyway! We are just wasting our time here with trying solving a problem we cannot tackle anyway."

Making clear to the team that we are working with a try-measure-learn model is a good way to shift their mind to a more positive attitude regarding the created action items.

The Last Step

Ok, so at the end of this phase, we have created a few small, actionable items to improve our process. Now we can continue with the last phase, Phase 5 - Close the Retrospective.

I will cover the details about Phase 5 in my next post of this series, which I am going to publish in about 1 week. So stay tuned and keep an eye on the blog.

Ok, that's it for today. See you around, HabbediEhre!