Here is my list of techniques you can use to write better Action Items for your teams and in your day-to-day work.  I have ordered this list from my favorite (#1) to least favorite (#5) techniques.

  1. Who-What-When: this is my favorite technique from the book Gamestorming (here is my 2013 review of this book).  There are two things I like about this technique: it begins with identifying who will do the work and it specifies when the action will occur (which provides a natural checkpoint).  For me, if no one is willing to accept responsibility for an Action Item, then what is the point of talking about what needs to be done?
  2. Who-Do: another very useful technique from the Gamestorimg book.  For me, I do not use this technique as often as Who-What-When, but it covers two of my Action Item pre-requisites: clear owner and a specific, observable and repeatable action.
  3. Merge: this is a fun technique (from the website Retromat) to use when a group has a habit of identifying many Action Items (more than five) but rarely follows through on delivering most of them.  The idea behind merge is to combine the best ideas from two dissimilar Action Items to create something new, interesting and unique that has higher likelihood of being completed.  On the Retromat site, it says to form pairs, then groups of four, groups of eight, etc.  IME, simply merging two Action Items into one is normally enough to create a meaningful and aspirational Action Item.
  4. Motivation-Ease-Reminder: another technique Retromat with the goal of creating Action Items that people follow through on.  For this technique, the group is asked to think about what motivates them to make the Action Item a high priority, what will make it easy for them to dedicate time to resolving the issue and how they will remind themselves the Action Item is a priority.  I use this technique when I notice that a group does not appear think through the execution of their Action Items.
  5. SMART Goals: this technique is a classic (I think I first read about it in the Agile Retrospectives book) and I used it for many years with good results.  Today, I do not use this technique much because they are really not that aspirational and for some people they can be demotivating.  I include SMART goals in this list because they have been around since 1981 and Scrum and Agile practitioners will encounter them at some point.