Foster Agile: Not Gonna Happen, Pt. 2

Part of the Foster Agile series.

In the original Not Gonna Happen post, I wrote about how my step-father says “not gonna happen” when I set some unreasonable goal for our work renovating my house.  The post focused on how his statement of hard limitations forced us to adopt realistic goals and why having realistic goals is valuable.  I just had a conversation with some Scrum Masters, though, and I realize there is another value of “not gonna happen” that the original post skated right past.  Long before we get into the benefit of realistic and well-crafted goals, we get the benefit of facing the truth.

Many if not most folks have at least some interest in working with others collaboratively.  We want to find solutions that make us all happy.  We want to help each other out.  So when someone comes at us with an unrealistic request, it is very, very hard for us to bluntly say, “not gonna happen”.  Not only are we afraid of them killing the messenger, but being that blunt feels…uncollaborative.  In fact, I wouldn’t be surprised if saying things that bluntly, even if dressed in slightly more corporate-friendly words, would result in the other person saying, “C’mon.  Why can’t you be reasonable?”

The truth is, steadfast adherence to one’s professional opinion of the impossibility of a given scope/time combination–i.e., sticking to “not gonna happen”–, is about as reasonable as you can be.  The trick is marrying that resolution to the truth with an attitude of cooperative invention, seeking and suggesting alternatives that could possibly work.  But that is one strange marriage: “not gonna happen” just doesn’t seem like it goes with the optimism of “here are a bunch of other options”.  If you let your desire to make things work out influence your sense of truth, “not gonna happen” turns into “won’t likely happen”, and then into “maybe it’s possible after all”.  Now the marriage is a mess, with neither partner true to itself: the truth of limitations is watered down, and the alternative plan probably hasn’t gone far enough to really address those limitations.

I now see the great challenge of keeping the marriage going in my head, between the hard “not gonna happen” and the soft “but, hey, partner, let’s work out some way that will happen”.  I recognize that I have often confused compromise with collaboration, trying in vain to compromise with the hard truth of limitations.  I’ll keep collaborating with others to find possible solutions.  However, going forward, when I really believe that something is simply impossible, regardless of the pressure put on me, I will try to say–and keep saying–, “Not gonna happen.”


A few years ago, I attended some training taught by Pete Behrens.   He led us through a number of collaborative exercises.   They had a number of common traits that I really liked:

  • very simple instructions, so we wasted little time figuring out how to execute (and so the facilitator didn’t have to spend hours explaining);
  • very short duration, so people didn’t get burned out, and so people did not deliberate at length over the value of the exercise;
  • small groups (often pairs), so even quiet voices had room to come out; and
  • frequent rotation, so the perspectives involved were constantly reshuffled.

I led a release planning meeting a month or two later, and I wanted to structure it around exercises sharing these characteristics.  I set up 3-5 activities.  Some were failures and some were so-so, but one stood out as valuable.  It is still popping up here and there throughout our organization.  Based on its longevity, I figure it’s worth sharing a little more widely.

To be clear: I honestly can’t remember if I made this up–inspired by Pete Behrens’ training–or simply repeated something he showed us.  I’m not interested in credit!  I just want more folks to know about this useful tool.


The exercise creates bursts of engaged discussion, typically about user stories.  Typically, this exercise would be used in backlog grooming, but you can also use it in release planning or sprint planning.

  • Write each story at the top of a blank sheet of paper.
  • Break into pairs.  Have one group of three if necessary.
  • Give each group one of the stories.
  • Give the groups five minutes to write down as many questions as they can about the story they have.
  • After five minutes, each group passes their paper to the next.  Give them 5 minutes to add questions to those written by the previous group.
  • Continue repeating until each group has seen all of the distributed stories.
  • Hand out the next set of stories, and repeat the exercise until you have gone through all stories.  If you can, shuffle the groups before distributing new stories.


Let’s say your team of seven is grooming a set of nine stories.  You would break into three groups (two pairs and one trio).  You would hand out three stories, and over the course of 15 minutes rotate those stories through all three groups.  You would then hand out three new stories and take another 15 minutes.  And a final repetition would finish the last three stories.  Nine stories reviewed by every team member in 45 minutes!

What’s Next?

In the simplest case, the Product Owner can go answer the questions and adjust stories accordingly.  Ideally, there is some later discussion of the answers.  Some groups here have posted all the questions and their answers on a wiki for later review.  Regardless, you have just gotten every team member thinking about every story in a very engaged way.

Facilitator Notes

  • Make sure people don’t try to answer the questions.  This is just about asking the questions.
  • If people do answer the question (say one person in the pair asks and the other happens to know the answer), make sure they write down the question anyway.  Just because they now know the answer, they shouldn’t cheat the rest of the team of that knowledge!
  • Regardless of how many stories/people you have, the math always works out that you need 5 minutes per story.
  • If the number of stories isn’t equal to the number of groups, you will have to adjust.  For example, with 10 stories, the example group could spend one round where one of the groups has two stories instead of one.


  • Many questions identified very quickly.
  • Helps make up for the impossibility of a Product Owner anticipating every question.
  • Avoids backlog grooming meetings where only the Product Owner and one or two team members actually talk.
  • Can take a meeting from boring to engaged, fast-paced, and even a little fun.
  • Flashes a light into corners that usually only get illuminated partway through the sprint.


  • Be careful not to let this be the only way your team discusses stories.  Some open group discussion is great as well!
  • “Query-Go-Round” is an awfully corny name for the exercise.

I’d love to hear about your experience if you give this a try.  Also please post a comment if you come up with a new application/hack for the exercise. Have fun!