July 25, 2014

Agile Coaching Blog

Spec Writing Game

Several people have asked for the hand outs to support the “spec writing game“, so I want to make those available to everyone. Let me offer a few guidelines for those of you who may choose to run the exercise

#1 – Take your time introducing the rules, it goes a long way towards making sure everyone knows what they are doing.

#2 – the Game works best when you have more than 4 people per team. With such small teams you are deprived interest dynamics of multiple people trying to work together (or not). Having a sole spec writer or developer introduces very different dynamics.

#3 – Give each team a little time before they start to organize themselves, this will usually lead to some interesting insights and may help them develop more innovative ways to work together. Remember, some people will really excel at this game and show powerful techniques to communicate and get feedback.

#4 – The instructions say 12 minutes, but I have found you can do it in shorter periods, as quickly at 5-6 minutes. However, a longer time period lets people get closer to a product and allows you to observe more behaviors (both good things).

#5 – While the facilitator doesn’t have much to do during the actual game, there are several things to observe and watch

  • How long does it take for the first spec to get to the development team (sometimes this can be as last as halfway through the round)
  • How much detail is in the first specification
  • Do teams try to split apart work. Some spec writing groups will write 3-5 sets of instructions at the same time, one for each element to be drawn
  • Do the analysts linger and watch what the developers do, or do they simply go back to their table
  • Once the specification has been completed, what do the spec writers do?
  • How do teams deal with confusion and mistakes?
  • Do the developers use things like component based construction (I have seen stickies or pieces of paper put together) or set-based development (I have seen teams drafting 3+ versions of the diagram at the same time, where they periodically throw out the ones that aren’t working and copy the one that the analysts say is closest)
  • Do the developers ever write questions for the spec writers?

As you can see, there is a lot to watch for. This is a great exercise, and is most effective when you do it with an actual team. Its especially fun to make non-technical people be “developers” and make the actual developers be “spec writers”. My one caveat would be to make sure you leave enough time for a proper debrief. Share your observations, ask teams what their experience was like, as people for specific things they did that were either particularly effective or ineffective.

I must acknowledge that I did not develop this game, but my search to find the original creator has been fruitless. This is the oldest reference I can find, so let me give some credit to the Scrum Trainer’s Gathering in 2008, as this is where I found it.

That’s about it. Good luck conducting this exercise and please let me know how it works out for you.

About Brian Bozzuto

Brian Bozzuto is a Senior Consultant and Agile Coach at BigVisible Solutions. With an extensive background in large financial service companies, he has worked as a developer, analyst, project manager, and coach. His current focus is working directly with teams as they adopt Agile and Scrum practices. He has a broad range of experience using various frameworks including Scrum, Six Sigma, and CMM as well as being a Certified Scrum Practitioner (CSP) and Project Management Professional (PMP). Brian has worked on numerous large integration projects involving enterprise portals and other web technologies. He has worked, in various roles, at Fidelity Investments, Investor's Bank & Trust, Bank of America, and Fleet Bank.


  1. Mick Maguire says:

    I tried it with my teams today for a fun refresher / reinforcer. It went down very well. I observed a lot of the facilitator watch points. The debrief clearly highlighted the levels of waste and frustrations.
    I did modify the exercise a little: I lengthened the timebox to 25 minutes and used my own “product vision” picture. I also extended the game with a second 25 minute round where, with a fresh “product vision” picture I allowed the spec writers to interact directly with the developers in a direct, immediate and conversational way. Nothing was written, no examples were given, they just conveyed the vision by direct face to face dialog. This second, more Agile round produced a much higher quality product in much less time. It was visibly easier and more engaging for everybody involved. I felt it clearly demonstrated and reinforced how Agile communication values and principles benefit the quality and speed of product delivery and really drove home the observations of the first round.

    Many thanks for posting this!