Agile Retrospective Exercise – How To Choose Vital Few Actions Which Has Higher Value?

The aim of an agile retrospective is to define actions for the next iteration that will improve the way of working and help teams to deliver more value to their customers. The vital few actions retrospective exercise can be used within agile frameworks like Scrum, SAFe, XP or Kanban to have teams agree upon the vital few improvement actions that they will do. By reducing the amount of actions and improving their quality, teams will get feasible and valuable retrospective actions which help them to improve themselves in a sustainable way.

In agile shorter iterations are usually better, as they speed up the feedback cycle and enable teams to learn and improve quickly. In short iterations there is limited room for change. You don’t want to have many actions, preferably only 1 or 2. More is less, if you have too many actions then you will get less done. Teams should focus on the vital few actions that they can do in the next iteration.

Too many actions

The purpose of this retrospective exercise is to destroy those retrospective actions that would be delivering lower value, so that only the essential ones remain that would result in changes that will stick.

You would do this exercise if you have too many improvement actions. For instance when there are many actions coming out of an exercise in a team retrospective. In that case you would do this exercise before you finish the retrospective meeting.

Most retrospective meetings start by checking the progress on the retrospective actions. It can be the case that there are many improvement actions from previous retrospectives that are still open. If the teams appears to be insufficiently able to do their actions then my suggestion is to do this vital few actions exercise. Don’t spend time on defining new actions when there are open actions that can be done.

This exercise can be combined with other retrospective exercises from the book Getting Value out of Agile Retrospectives like the one-word retrospective, strengths-based retrospective or project collaboration retrospective. It can also be done as a stand-alone exercise in the retrospective meeting.

Destroying actions

There are different techniques that can be used to destroy retrospective actions to help teams to focus on the vital few actions:

Dot voting: Every team member gets a limited number of dots which they can use to vote on the improvement action. They can cast their vote by putting dots on the the action. Distributed teams can use Google docs or sheets or online collaborations tools to do the voting. Votes should be given to actions that provide the most value when done in the next iteration, assuming that those actions are feasible. Team members are encouraged to give multiple votes to an action, since that stimulates them to focus.

Remove the bottleneck (lean): The team is asked to look at the main flow in the iteration. They start from delivery and go back until the beginning to find the biggest bottleneck in their product development life-cycle. Next they have to pick one or more actions that help to reduce this bottleneck, and to throw away all other actions.

Devil’s and Angel’s advocate: The team starts by playing the role of the devil’s advocate. They pick one action which they think has the least value for the team by together bringing up reasons why it wouldn’t work or doesn’t solve their problems. When only a few ideas are left they change their role to the angel’s advocate to bring up ideas why these actions *would* work. Finally they would pick only 1 or 2 actions that they think would give the most value in the next iteration.

Kill actions: Team members are asked to destroy actions that they think have the least value. Initially every team member is allowed to give a veto against 1 action. I usually suggest that veto’s don’t have to be motivated, since by voting against an action a team members are stating that they do not support them and will not contribute to get the action done. Team members are allowed to give veto’s to the same action, this will help to identify actions for which there is no commitment in the team. When there are still too many actions left, another round is done until the vital few actions are left.

It helps to physically destroy actions that are removed,  for instance by throwing away the sticky note, wiping out the action from the white board or deleting the action from an electronic action list. This ensures that team members will focus on the remaining actions as those are the only ones which are still visible. If team members are unsure if they can do without the action then you can tell them that if it was a valuable action then it will pop up in a future retrospective.

You can refine the remaining vital few actions using results from the techniques described above. E,g. by discussing why people voted on an action, exploring the bottleneck or using feedback from the Angels advocates. Alternatively you can do a perfection game to improve an action.

Teams travel their own agile journey

One of the benefits of retrospectives is that teams are empowered to taken action. They can decide which actions they will do. Agile teams are responsible for their own improvement journey. By self-assessing how agile they are and designing valuable agile retrospectives teams can become agile and lean.

Agile iterations are short, so teams can only do few actions. Having a big list of actions doesn’t help, it is better for teams to focus and to assure that the vital few actions get done!

How to Communicate Effectively With a Remote Team