9

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?

Rob
  • 361
  • 1
  • 12
  • 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

4 Answers4

8

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.

Malfist
  • 3,641
  • 5
  • 29
  • 40
  • 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
6

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.

maple_shaft
  • 26,401
  • 11
  • 57
  • 131
  • 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
  • @unforgiven3, Any developer that is not at least somewhat familiar with Minecraft must turn his geek card and be escorted off the premises immediately :) J/K. Kidding aside, all they would need to know is that it is an insanely addictive game where you control a guy who can lay blocks and jump. The point of the exercise is not to be accurate about individual tasks for the user story but more for anticipating that the customer probably doesn't REALLY just want a building surrounded by a moat with no bridge. The need for the bridge should be implied. – maple_shaft Aug 30 '11 at 14:06
  • @maple_shaft, I am embarrassed to say I have never played :) but I am familiar with it. I see what you're saying, especially about the need for a bridge being implied. I think I'll whip up a little PowerPoint exercise explaining the activity and post it back here. Would you be willing to give me some feedback on it? – Rob Aug 30 '11 at 14:11
  • I've never played Minecraft but I think the analogy works perfectly well. You should also add that the client wants an extra wall to be X height, but he hasn't decided on X yet and he'll let you know "ASAP". – Graham Aug 30 '11 at 14:23
  • @unforgiven3, Sure! If you google image search 'Minecraft Pyramid' you can actually FIND a screenshot of a pyramid surrounded by water with a bridge. I wouldn't show that screenshot however until after that presentation. There is a free version of Minecraft that you can play online too if you want to become more familiar with it. – maple_shaft Aug 30 '11 at 14:26
  • An implied requirement? Absolutely not. If the user wanted a bridge, they would ask for a bridge. If they didn't say it from the beginning, a good requirements engineer would ask about it. But it would absolutely not be shipped to the customer if it wasn't in the spec. – Thomas Owens Aug 30 '11 at 14:58
  • 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
  • @Thomas, I actually agree with you, this exercise doesn't actually teach how to estimate, they are disjointed however one begets the other. Poorly thought out requirements will render even the BEST estimates useless. In the real world, requirements analysis is so critically important for the developer to do because the developer is the final stop. He is the final protection against bad requirements, much like how a good nurse will question a doctor who makes a dangerous mistake. If the doctor orders the wrong dose and the nurse kills the patient, THEY BOTH GET BLAMED. – maple_shaft Aug 30 '11 at 15:19
  • @maple_shaft This question is explicitly about improving estimation skills, though. If you need to improve estimation skills, your tasks should assume perfect requirements so that you can focus on the actual task of improving estimation. Introducing too many variables just makes it more difficult to learn and teach a concept. – Thomas Owens Aug 30 '11 at 15:27
  • @Thomas Owens, I definitely agree that a good engineer should always be improving both. I think that requirements discovery might be a better activity for my presentation, though, I will use an activity on requirements as a lead-in to a small discussion on estimation. Thanks, everyone - you guys have all been hugely helpful! – Rob Aug 30 '11 at 15:29
1

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...
Whiskas
  • 111
  • 1
1

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.

Jonathan Cline IEEE
  • 906
  • 6
  • 8