Retrospective Exercise: Vital Few Actions

RetroValue ImproveThe 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!

Are you interested to spice up your retrospectives using new exercises?

Here’s a list of exercises that you can do to get business value out of doing retrospectives. You can attend one of my workshops on Valuable Agile Retrospectives to learn how to adopt agile retrospectives and become agile in an agile way. Or download one of my books with retrospective exercises. Feel free to contact me if you want to discuss the possibilities.

Ben Linders

I help organizations with effective software development and management practices. Active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer.

This Post Has 5 Comments

  1. Rolf


    very helpful hint! For people who don’t like the “killing” / “destroying” metaphors, Fabian Schiller’s “priority race” might be a more positive decision-making activity (the best actions will win):

    There’s also the inverse problem: people absolutely agree something “must” be done, but there’s no option that looks like a clear winner. When resistance is rising, systemic consensing might be a helpful decision making technique:


  2. BenLinders

    Thanks Rolf for your responses. I like the priority race, on the surface it looks similar to dot voting but the different way of visualizing the options and having them compete makes it valuable.

    Systematic consensing can also be useful. The zero option can help to come to a complete/unanimous team decision, but there might also be cases where not everybody has to buy in and agree.

    One other technique that I use in for instance CMMI assessments is thumb voting. Thump up means you agree, down you disagree, and sideways that you will go with what the majority of the group decides.

    Great contributions Rolf, again thanks!

    (link has been corrected 🙂 )

  3. Bill Wilson

    Hi Ben, I like this article very much. Not being in a software development/engineering environment, I don’t have any practical experience with Agile methods and techniques, and the only knowledge I have is from reading various blogs over the years. I’ve had kind of a minor academic interest in the subject, but this post has made me realize that Agile could make a leap from software engineering to other engineering fields. My particular industry (nuclear power) employs large numbers of engineers working on system performance, equipment reliability, components and engineering programs, design, projects … and every one of these groups at my company is looking for ways to achieve excellence. Agile could be the key. Thanks for opening my eyes to this!

    1. BenLinders

      Bill, thanks for your kind word!

      Actually agile has made the leap already to other areas. For instance in education with eduScrum and for continuous improvement. I’ve heard from hardware teams that use agile to develop products and agile marketing teams. Our books are being translated with self organized agile teams of volunteers. There a management teams who have adopted agile to become more effective.

      I do not have any examples from nuclear industry but I wouldn’t be surprised if people would use it there also.

      If you decide to use agile practices with your teams I’d love to hear how it works out. Feel free to let me know!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.