How to Run the #NoEstimates Puzzle Experiment v1.0

Tags: noestimates, experiments, games

Given the considerable interest and heated conversations that were generated by the #NoEstimates Puzzle Experiment this past weekend at Agile Coach Camp Canada (not to mention the enormous fun that Alexei Zheglov and I had facilitating), I thought it might be a good idea to share my Preparation and Facilitation Notes so that others could get in on the fun with their own teams and user groups.

What follows is Version 1.0 - expect revisions in the coming days and weeks as I run the experiment with more groups.

I think it critical to remind participants that the objective of the experiment isn't who can deliver the most value - it's not a race - but rather to generate critical thinking about why one team or maybe both arrived at their results and in the process make new discoveries about software delivery. Keep it friendly, and be prepared for some pointed comments from participants on all sides of the debates. This isn't an experiment for the faint of heart!

Good luck!


  • Two identical puzzles of around 650-700 pieces; I recommend anything in the Ravensburger line. In the first run of the experiment, I used a 1,000 piece puzzle of the Painted Ladies row homes in San Francisco, removing the blue sky and green grass parts to reduce sorting time for each team.
  • Sharpie marker pens
  • 4x6 cards for writing user stories
  • Enough planning poker cards for one team - I limited each hand to 0,1,2,3,5,8,13 but you can use whatever suits you.
  • Two tables big enough for each team to work on.
  • Camera phone to take photos or video of the proceedings
  • Timer - either or a phone to track the two main 20 minute time boxes.


  • You'll need 8-10 participants divided into two teams; each team selects one of their members to be the Product Owner or customer.
  • Two facilitator/Scrum Masters (ideal), one for each team


  • Furnish each table with a jigsaw puzzle, 4x6 cards and Sharpies
  • Assemble teams around each table

Start: Opening Briefing

One or both of the facilitators explains the rules of the experiment to the participants:

Welcome to the #NoEstimates Puzzle Experiment!

You've been selected to participate in an experiment to better understand the role of estimates in team-based, agile software development. By participating, we hope to provoke interesting conversations amongst yourselves and the community about whether estimates are necessary to produce quality software products. The outcome of this experiment is highly uncertain and unpredictable. It is dependent upon the people participating, their experiences and ability to collaborate well with each other under conditions of extreme uncertainty - just as with a real-world software development project.

In this experiment you will be building a jigsaw puzzle according to the Definition of Value set out by your Product Owners. Just as with real-world software projects, you will be challenged to meet this goal within a time constraint: Approximately 40 minutes.

Product Owners: It should be apparent that your teams are very unlikely to solve the entire puzzle within the time constraint, so you will need to focus on a particular aspect of the picture you want your team to deliver. This can be anything you like, but we recommend something that is visually interesting, cohesive and plays to the strengths of your new team.

NEW: Team Selection

Facilitator has participants break into two even-sized teams (usually 5-7 people each) and uses a coin toss to determine which will be Scrum Team A and "Mob" Team B. This can be done on the call of the selected Product Owners or by the facilitator. After the team types have been decided, the facilitator continues:

Teams: You will be using agile practices to deliver increments to your Product Owners.  Team A: You will need to self-organize and use the Scrum Framework.  Team B: You will be self-organizing as a "mob" using a "flow" delivery approach.

Team A Briefing

One facilitator explains the order of play:

You have about 40 minutes total time to deliver your solution using the Scrum Framework. This is a suggested plan:

Product Owner:  You begin the experiment by explaining your Definition of Value to your team and what aspect of the puzzle you want them to deliver.

  • Sprint Zero: Plan with Product Owner, get familiar with the puzzle, write user stories. (5 mins)
  • Sprint 1 Planning: Estimate user stories, break down epics as required. (3 mins)
  • Sprint 1: Work on delivering against stories. (10 mins)
  • Sprint 1 Review: Collaborate with Product Owner to review delivered increments, check for "done-done" (2 mins)
  • (20 minutes total)

Sprint 1 Retrospective: Reflect on process, inspect and adapt as required (2-3 mins)

  • Sprint 2 Planning: Write new stories, re/estimate as required (5 mins)
  • Sprint 2: Work on delivery. (13 mins)
  • Sprint 2 Review: Collaborate with Product Owner to review delivered increments, check for "done-done" (2 mins)
  • (20 minutes total)

Team B Briefing

One facilitator explains order of play:

You will follow Team A's time boxes: Two 20 minute iterations with a 2-3 minute retrospective in between.  You may begin at the same time as Team A.  You are free to self-organize as you see fit within each 20 minute time box, but we recommend the following order:

Product Owner:  You begin the experiment by explaining your Definition of Value to your team, ie. what aspect of the puzzle you want them to deliver.

Team: Write user stories to meet your PO's Definition of Value and help them build an ordered backlog of features. Note that you may decide to illustrate your stories instead of using the standard "as a... I want... so that..." template.

You may begin working on delivering a feature as soon as the PO releases it to you, however, you may not work on a subsequent story until the previous one has been accepted as complete by the PO. After each story is complete, you can use it to gauge how much more "functionality" to "slice" off from the backlog to deliver another "done" increment.

It's up to you to decide how you want to self-organize around the task of solving the puzzle under the direction of your PO.

Product Owner:  At any time you may decide to alter the path your team is taking in pursuit of your Definition of Value by writing a new user story and ordering it for delivery after the current increment. For example, you might decide, based on the team's feedback, that it is more advantageous to assemble an element of the puzzle for which they have more sorted pieces available.

First Sprint Facilitator Notes:

  • Once teams have been briefed and all questions answered, set a big, visible timer to 20 minutes for the first time box and start it.
  • Once the teams have begun the experiment, monitor their progress closely and provide "coaching" assistance where required according to your judgement. 
  • Remind teams of the remaining time at critical points, eg. 10, 5, 3, 1 minutes left in "regulation time".
  • Don't forget to take pictures and/or record video of the proceedings of your team!

First Retrospective Notes:

  • Set a time-box for 2-3 minutes.
  • Ask each team's Product Owner about their observations and how confident they are that their teams are on track (scale of 1-10)
  • Ask each team about their observations and how confident they feel about meeting their PO's objectives. (scale of 1-10)
  • Remind each team that they can use this time to re-set and inspect and adapt their process and product plans.

Second Sprint Facilitator Notes:

  • Monitor teams and provide guidance as required to keep the teams aligned with their Product Owners and the Product Owners aligned with their goals.
  • Remind teams of the remaining time at critical points, eg. 10, 5, 3, 1 minutes left in "regulation time".
  • Don't forget to take pictures and/or record video of the proceedings of your team!

Final Retrospective and Closing Briefing:

  • Once the time boxes have expired, ask each team's Product Owners how many increments of value their respective teams have delivered, and how many of them they accepted as "done-done".
  • Ask Team A to provide their observations and experiences using estimates to govern their delivery
  • Ask Team B to provide their observations and experiences without using estimates to govern their delivery
  • Allow conversation to flow as long as necessary.
  • Conclude by thanking everyone for their participation and noting that the real point of the experiment has been achieved: To generate serious conversation and thinking about whether estimates are required to deliver quality software and what alternatives might exist through critical thinking, experimentation and observation.

Post-Experiment Actions:

Post your experiment's observations on your nearest wiki or blog and broadcast across Twitter including the hashtag #NoEstimatesPuzzleExperiment - and reference me in if you can (@DerailleurAgile). Share the good and the bad and your thoughts on how it could be made better.

blog comments powered by Disqus