Actionable Agile Tools - a book review

From the Requirements Management Ruminations Blog
by , , , , , , , , , , ,
A collaborative blog with contributions from members of the PMI Requirements Management Community of Practice and various authors and presenters who have dealt with the topic of requirements management.

About this Blog


View Posts By:

Cameron McGaughy
Abdulilah Angaa
Mike Frenette
Beth Ouellette
Victoria Cupet
Jhansi Vijayarajan
Bobbye Underwood
Sally Elatta
Rich Larson
Elizabeth Larson
Ellen Gottesdiener
Mary Gorman

Recent Posts

Natural Language Processing to sharpen up your requirements

Automating requirements review using Natural Language Processing

Actionable Agile Tools - a book review

What’s Hot and What’s Not--Trends in Business Analysis Webinar Follow-up

Project Managers Find New Rhythm at PMI® Global Congress’ First Agile Open Jam

This Blog is about requirements management, so a book I read recently about Agile tools seemed to apply since some of them are about managing the Product Backlog. 

"Actionable Agile Tools" is the name of the book, and it was written by Jeff Campbell.  It is a short book - a compendium of tools he has developed over the last ten years as a Scrum Master and Agile Coach.  Jeff is Canadian, but has been living in Sweden for many years.  I met Jeff at an event called a "Scrum Beers", which is a gathering of people who use Agile.  They meet for presentations, followed by some informal networking and libations.  Scrum Beers is really about Agile, not just Scrum, and is now present in three countries. Check it out at

If you buy the book at, you can tweet about it at #actionableagiletools.

So - on with my review!

First of all, I must say that Jeff has given some innovative names to some of the tools he mentions. I hope you enjoy the names as much as much as I did.  The book is simply structured with a brief introduction and then a chapter on each of the tools.  I’ll comment on each of them, but of course you really won’t see the whole picture until you read the book.

  1. Experiment Driven Change – Fixing things found in retrospectives by experimenting with a change immediately, and tossing it out or keeping it when you discuss it again at the next Retrospective.  This tool is meant to stop the “never do anything but talk about it” syndrome.

  2. Door Calendar – An information radiator about events you can create with some simple sticky notes.  Put it on a door the team uses every day.

  3. Doing Dots – Put a dot on a post it note reminder to do something every day nothing changes. These notes might be on your Kanban chart or other card wall.  The more dots, the older the item. This stops things from not getting attention (lots of dots? Needs attention!), or becoming fixtures that everyone ignores.

  4. Bugs for Breakfast – Increase your quality focus by having a team breakfast on a regular (start with weekly) basis where the main discussion is about bugs and how/when to fix them. 

  5. Communication Protocol – Discuss with your team all the means of communication you have and the pros and cons of each. Gain team consensus on how, why and when each should be used.

  6. Tasty Timeboxes – Have food at Sprint Reviews, but make it different food for each Sprint.  This allows people to easily refer to past Sprints and also gets some team spirit going as you choose the food for the next Sprint. For fun, you can use the alphabet to choose the food. Remember the Chicken Curry Sprint and how Maggie said…

  7. Where Does the Time Go – Categorize time such that in the daily Scrum each team member reports on the category into which the time they are talking about falls.  Was it planned?  Critical? Support? Admin?  This highlights productive versus wasteful time.

  8. Event Log – Keep track of events during a Sprint on a large sheet (date/event) to be used at the Sprint Retrospective. Make updating it a daily ritual.

  9. Resilience Map – List the skills (rows) you need on your team, then map it in a large matrix you put on the wall showing the level of skill (columns) each team member (multiple per cell) has in each skill area. Keep it up to date as the team changes.  This lets you know who has what skills when people come and go or need help. It also acts as a tool to see where you have skill shortages on the project.

  10. Recruitment Retrospectives – Empower people joining the team to invite anyone they want to retrospective meetings to discover holes in the on-boarding process. Create specific experiments to plug those holes and follow up on them. Use the newest person in on-boarding the next new hire.

  11. Appreciation Flowers – Give a post it note with your team members name and flower drawn on it for them to take back to their desk.  Write on the back of the note why you are giving them a flower.  A great and no cost why for people to show appreciation.

  12. Value Poker – Like Planning Poker where the relative complexity of stories are set by the team, this allows stakeholders to rate the value of each story.  Helps you understand the business value of each item so you end up with a Prioritized Product Backlog.

  13. In-Line Definition of Done – Make a checklist of items that must be ticked off before something can be considered “done”.  Put it against the story, not in some place that won’t be noticed until someone says something is done.  Helps your team focus on what “done” means.

  14. Not Now Backlog – Choose a timeframe with your team and stakeholders beyond which you will not consider items for the backlog. Rather than throwing out the ideas, add them to the Not Now Backlog.

  15. Visualized Flow – Use a Kanban Board to show In-flows and Out-flows – that is, the movement of a story from its inception showing who came up with it, through refinement (by the Product Owner and by the Team) until ready, and finally done.  This allows anyone to see the status of work as it goes through each stage until it is finished.


Posted by Mike Frenette on: January 18, 2016 11:44 AM | Permalink

Comments (11)

Please login or join to subscribe to this item
Nice book and great review. Thanks

Nice introduction. Still need to read book

Very important these tools to collect requirements. The basis of any project are the requirements. That is why we must focus on the most collect them, understand, communicate.

Now I need to look it up.
Any other books on Agile for Enterprise or other field than IT??

Great Thanks

Something I will be reading. Thanks

Thanks for the positive comments, everyone.

@Vincent - I recommend the book Practitioner's Guide to Requirements Management
2nd Edition, published by Watermark Learning and authored by Elizabeth and Richard Larson. Elizabeth and Richard were also authors of PMI's Business Analysis for Practitioners Practice Guide. In there you will find plenty of practical advice on Requirements Management, including multiple methods.

Great review, thanks for sharing!

These tools are great! Thanks for sharing them.

Please Login/Register to leave a comment.


"I only hope that we never lose sight of one thing - that it was all started by a mouse."

- Walt Disney