I'm putting together a presentation to deliver to some of my teammates (all developers), and I'd like to include a short team building activity that focuses on improving estimation skills. Does anyone have any suggestions or know of any team building activities I could use?

  • 2
    Improving estimation is not something that can be done with a short activity. It has to be a long-term effort to track your estimates, actual times, and some kind of postmortem to determine why the estimate and actual time were different. It's also a skill that develops over time - you get better by estimating and learning from your mistakes through analysis.
    – Thomas Owens
    Aug 30 '11 at 13:14
  • Do you have a problem? How accurate are your estimates and should you take the time to improve them?
    – JeffO
    Aug 30 '11 at 13:23
  • @Thomas Owens, I'm aware that it's not something that can be done with a short activity. I'm just trying to increase awareness of the importance of developing good estimation skills. I should have been more specific in my question.
    – Rob
    Aug 30 '11 at 13:42
  • 2
    @Jeff O, no problem - these are new hires, some with less experience, and I want to help them work on estimation in general.
    – Rob
    Aug 30 '11 at 13:43

Check out Joel On Software's Evidence Based Scheduling, it's a fairly simple way for people to figure out how estimate more accurately.

The best way to learn how to estimate is to have good requirements, practice, practice, and practice. Teaching them things like Evidence Based Scheduling will help the practice be more effective, but nothing can replace actual practicing.

  • I do love me some EBS (I'm an avid FogBugz user). I didn't think about using it as an example, though - good suggestion. I'll take some inspiration from it.
    – Rob
    Aug 30 '11 at 13:45

Present an example problem using Minecraft.

The customer needs a brown step pyramid that is 20x20 blocks. The pyramid also needs a moat that is at least 10 blocks wide.

Give them 3 minutes to sketch up a simple WBS and an estimate.

2 minutes in, say that the customer changed their mind and they need a 30x30 pyramid now. Tell them to revise their estimates in the remaining minute.

At the end of the time tell them to put their pencils down, and now say that the developers start working on the project but the client is confused because there wasn't a bridge going across the moat.

Tell them that the bridge would take X hours to develop and ask for everybody who underestimated to stand up.

This will drive the point home.

  • 2
    I like this, but if you're not familiar with Minecraft, I'm not sure how you could come up with an estimate that makes sense. How would you quantify the time it takes to build a brown step pyramid?
    – Rob
    Aug 30 '11 at 13:49
  • 1
    @Thomas Owens, I think maple_shaft point is to impress on the developers the importance of discovering those types of requirements. As a consultant, I've personally seen many examples of ridiculously obvious things that a user should have asked for, but didn't, because they did not realize it was what they needed. Myself and my developers are all consultants, and in our current situation, we do not have the luxury of good requirements engineers, which is why I am trying to help prod them into asking those types of discovery questions of their clients to help improve their estimations.
    – Rob
    Aug 30 '11 at 15:02
  • 2
    @unforgiven3 That has nothing to do with estimation, though. The job of requirements engineering might fall to a developer, but you can only base your estimates off of known requirements. Improving your ability to analyze, verify, validate, and discover requirements is disjoint from improving your ability to estimate how long it will take to perform a task. Requirements change, estimates therefore change, but it's impossible to estimate what you don't know and you shouldn't be trying to.
    – Thomas Owens
    Aug 30 '11 at 15:04
  • 1
    @Thomas Owens, I agree it's impossible to estimate what you don't know - which is precisely my point - you need to discover requirements for a feature and validate assumptions about it as a prerequisite for creating a decent estimate. I do agree, though, after some consideration, that it is disjoint from improving one's ability to estimate - perhaps focusing the activity on discovering requirements would be more immediately useful than an estimation activity. Good points - they definitely have me thinking that maybe I am focusing on the wrong skill to improve.
    – Rob
    Aug 30 '11 at 15:15
  • 1
    @unforgiven3 A good engineer should always be working on improving both. I've been in a position where I was not tasked with requirements engineering, but I was handed a spec that had what I saw were problems in it. Having the skill to see those and ask the right questions is essential for anyone developing software, and it does need to be worked on. However, when I am estimating, I always based my estimates on the spec, even if there are questions. I just leave a larger window for error (giving 75% chances instead of 85%, or giving a slightly larger window).
    – Thomas Owens
    Aug 30 '11 at 15:19

I suggest a labyrinth generator/solver for the following points :

  • It is fun to do
  • You can't think of all the cases for the first time
  • The generation and solving stuff are quite complementary
  • This covers from back-end with data saving to front-end with data loading
  • Many points can be assigned to people : file specification, display, generation, solving, optimization, testing etc...

You can play the "How long would it take you to write this?" game. Similar to a group of people bragging about how they can drive to Las Vegas in X hours (where the number X usually decreases with each braggart until someone claims they can do it in under an hour). So for coders: Throw out a simple goal and see what each individual says and if there is a consensus by the group or standout opinions. How long would it take you to write hello world? What does "write" mean, does that mean "run" and "test" too? Does it require a simulation environment first? On which platform and which cross-compiler and are the tools already installed and ready? etc etc.. "Hello world" might take 4 days to "write" on an embedded platform (install tools, get platform ready, re-install tools because it went wrong, fix the JTAG problem, troubleshoot the serial port problem, work around the limitations in the IDE to make a compilable project, finally take 5 minutes to write the code, compile it, fix the link errors and the memory map, re-write the code to use the correct bootstrap, re-compile it, get the final link, then download it, fix the JTAG problem again, finally run it to get output).

After the team finishes deciding how long the goal might take, then measure how long it actually takes (perhaps not for the suggested goal but for a real-world similar one) or recall a previous project with very similar goal. Compare estimate to actual. Wildly exaggerate the error between the estimate and actual and publish a conclusion for all.

Not the answer you're looking for? Browse other questions tagged or ask your own question.