What Were They Thinking?

Stay Updated: Posts | Comments   Follow us on Twitter


30 mins


  • Supplies for each team: play dough, pipe cleaners (chenille stems)


Each team selects one Business Analyst (or Product Owner) to come look at a picture of an item that a customer wants built. The BA’s are instructed to only use imperatives and similes (no ‘rhymes with’) and to not use certain words (like the game Taboo) when describing the item to the rest of their team.

  • In round 1, the item is something simple (such as a chair), but the BA must communicate only in writing. This should only take a few minutes for the team to create using the given supplies.
  • In round 2, the item is something simple (a teapot), but the BA can speak with their team. This should show how much easier it is to communicate by speaking.


Note: A quicker alternative to this game is to have teams draw the items instead of using the supplies.

Learning Points

  • In software, we are rarely creating something that already exists. Without a common vocabulary, we are forced to communicate in imperatives and metaphors and, quite often, much is lost in translation.
  • Iterative development with demonstrations allow us to hone in on what is really needed, rather than what is asked for.
VN:F [1.9.16_1159]
Rate This
Rating: 4.4/5 (10 votes cast)
What Were They Thinking?, 4.4 out of 5 based on 10 ratings
Print Friendly
7 Responses to "What Were They Thinking?"
  • Lodewijk Bergmans December 14, 2009 at 3:24 pm

    I am very much in favor of activating people when learning, and preferably in a fun way.
    I do think this is a nice exercise, but I am wondering to what extent we need to let people experience “In software, we are rarely creating something that already exists. So we are forced to communicate in imperatives and metaphors and, quite often, much is lost in translation.”

    Certainly almost every developer is aware of this, right?
    Now I am wondering if this could be improved (and e.g. “Mr. Happy Face” does a better job at that) to let people experience an alternative way of working: indeed the difference in round 1 and 2 is doing that, but the overall feeling after the game will remain: we have a problem (as we already knew).
    So why not have (equally difficult?) assignments where in the last round, additional iteration/feedback cycles are allowed, to show that the result is actually better? (or even continuous feedback while the team is working…)

    You could even introduce economics in it, perhaps? -> e.g. cost per time unit, every time you iterate, costs additional, delivering the wrong thing will yield nothing.

    If I am on the wrong track with my suggestions; please enlighten me!

    Lodewijk Bergmans

    PS: especially when drawing, this is much like the party game ‘pictionary’–great fun indeed

    VA:F [1.9.16_1159]
    Rating: 5.0/5 (1 vote cast)
  • Michael McCullough December 14, 2009 at 4:12 pm

    Hi Lodewijk!

    Thanks so much for your comment. I agree, many developers understand the imperfection of language to completely describe what is fundamentally an uncertain goal. The intent of this game is to illustrate that point to those less familiar with the nature of building software.

    The idea of changing the game to illustrate the need for feedback in empirical processes sounds really interesting. I wouldn’t say you’re on the wrong track in any way. It is just not the path we went down when we created the game. I would be interested in hearing how this works for you. Perhaps you could even post it as a new game!


    VN:F [1.9.16_1159]
    Rating: 0.0/5 (0 votes cast)
  • Mike Pearce October 18, 2011 at 8:27 am


    For the hard of learning, what is an ‘imperative’ in this game? Could you give an example?



    VA:F [1.9.16_1159]
    Rating: 0.0/5 (0 votes cast)
  • Michael McCullough November 27, 2011 at 2:44 pm

    Great question Mike.

    So by imperative I mean a statement like ” It shall ….” or “It must …”

    Hope that helps,

    Mike McCullough

    VN:F [1.9.16_1159]
    Rating: 0.0/5 (0 votes cast)
  • Amber July 18, 2012 at 12:29 pm

    What words would you not allow them to use when describing the item? Obviously Chair, but what other descriptive words would you leave out?

    VA:F [1.9.16_1159]
    Rating: 0.0/5 (0 votes cast)
  • Don McGreal July 19, 2012 at 8:37 pm

    Hi Amber,

    The taboo words I use are:

    For Chair: sit, seat, stool, rest, furniture, table
    For Teapot: tea, pot, short, stout, coffee, water, heat
    For RV-Bike: motorcycle, bike, camper, rv, trailer, chopper, harley

    Of course, these may need to be adjusted for different audiences and cultures.


    VN:F [1.9.16_1159]
    Rating: 0.0/5 (0 votes cast)
  • Don McGreal August 9, 2013 at 7:56 am

    A few notes on how this exercise has evolved for me over the years:
    1. I only ever have them draw, rather than use play dough or pipe cleaners. I get the same results and it is a lot easier to prep and a lot less messy.
    2. For larger groups, I pair people up (one a product owner and one a developer) and have the developers face away from the projector screen, which displays the image and taboo words. This is quicker and smoother than having a PO come up and write down the taboo words.

    VN:F [1.9.16_1159]
    Rating: 5.0/5 (1 vote cast)
Leave a Reply:

Spam Protection by WP-SpamFree


Discuss Comments
Agile Games Group