I’m continuing the series of reports from the 2013 Agile Coach Camp Canada started with the previous post.

The opening night of the camp was the games night and the highlight of it was definitely was the debut of Chris Chapman‘s new game, which he has recently designed to demonstrate that the estimation of upcoming work can sometimes get in the way of delivering value to customers. This game was inspired by Woody Zuill, who leads the informal #NoEstimates movement, which challenges software development practitioners to get out of their comfort zones and question the value they get out of their estimation activities. (Here is the collection of Woody’s blog posts on this topic.)

Chris and I met in Toronto for dinner a week earlier and he demonstrated to me the design of his game. We discussed it, I suggested a few improvements. He included them in the game design, purchased the materials, ran some experiments during the week and offered me to help him facilitate the first run of this game during the coach camp.

The game participants made two teams and received the same project to assemble a jigsaw puzzle. Chris and I chose the picture of the San Francisco Painted Ladies as our jigsaw puzzle picture, because it had many distinct architectural and landscape elements in it, giving the teams’ product owners lots of choices in defining value. The picture in the actual puzzle was a little bigger than the picture above and included a lot of green (grass) and blue (sky) pieces, which Chris removed from the puzzle boxes to simplify the project.

One of the teams had to skip estimation and simply try to get some work done. They would ask their Product Owner (John MacIntyre played this role during the coach camp) right away what area of the puzzle he wanted them to work on and start assembling it right away. They would demonstrate progress to the Product Owner frequently and ask for feedback. If the Product Owner was satisfied with that area of the puzzle, he would give them another are to assemble next. The team and the Product Owner would then keep going until we all reached our time limit.

The other team was the control team in this experiment and had to follow a more traditional iterative Agile approach. They had an Iteration Zero first to populate the product backlog with a few “stories” that the Product Owner (Maria Kouras played this role) identified as the most valuable. After relative estimation of the stories using planning poker and quick prioritization of the backlog by the Product Owner, the team would select some stories into their Iteration One and start the work. The iteration was supposed to be followed by a quick retrospective and some necessary adjustments. The Product Owner would get an opportunity to reprioritize the backlog at that point. The team and the Product Owner would then keep repeating their iterations until the end of the game.

Both Product Owners were told that their definitions of value may change during the game, simulating the real-world possibility that customers (and Product Owners representing them) can change their mind about what they want after they have seen the first delivered increments of the product.

Chris facilitated the first team, I facilitated the second, so I can tell you mostly what was happening on that second team. The second team used their Iteration Zero to create several items in the backlog and estimate them on a Fibonacci scale, mostly in the 8-13-point range. After the Product Owner stated her priorities, the team decided they could select only one 8-point story for their first sprint. They could not deliver it during the sprint, the Product Owner didn’t accept anything, and it was clear that the stories were simply too large or what we in Agile software development would call epics. The team broke down the story into several smaller stories and, to estimate them, they chose to skip planning poker and simply assume that each new story split off the original 8-point epic was worth 1 point. Their velocity in Sprint 2 was finally above zero, but it was exactly one story point.

The first team clearly managed to assemble a larger portion of the puzzle than the second team, but the real punchline was delivered by Yehoram Shenhar who played on Team 2: “Which team has learned more?” He was not suggesting it was his team. Here are the final results achieved by the teams by the end of the game:

I noticed during the game that Team 2 ran all the Scrum process elements (writing user stories, prioritizing the backlog, playing the planning poker) very smoothly, because they had several very experienced agilists on the team. My initial conclusion was that we needed such people on the “traditional” team in order to run the game. However, when Chris brought this game to our Agile user group gathering in Kitchener ten days later, we had less experienced players on this team, but achieved pretty much the same results.

Finally, you should read Chris’s own blog posts with reflections on this game! (And also his follow-up posts here and here.)