Previous: The Role of the Team – Next: Learn from other Teams
Don’t know what you don’t know (Jim McCarthy, 10 min)
An excerpt from a software development speech that Jim McCarthy gave to Microsoft Consulting when he was in charge of C++ (now Visual Studio).
Very enlightening and funny speech excerpt about how projects are (typically) estimated and why this fails.
Agile Development Teams: Scope and Scale (Mike Cohn, 10 min)
The quick introduction to planning and estimating a Scrum Project.
Agile Estimation and Planning Poker (Mike Cohn, 90 min total)
Mike Cohn gives us an understanding why we shouldn’t plan projects in the large using absolute times. We as humans are much better estimating relative orders of scale, scope or magnitude. Everyone can relate to the example he gives: how much bigger is an Elephant compared to a Lion? We can estimate that pretty easily and chances that we’re off by more than a factor of 2-3 are slim. Especially if you use the average of several estimations. But when we try to estimate the elephant’s weight and how much more it weighs compared to a Lion, we’re usually off by several orders of magnitude – multiplied by the number we’ve seen ten seconds before on the fortune wheel!
The idea behind Planning Poker is simple. Individual stories are presented for estimation. After a period of discussion, each participant chooses from his own deck the numbered card that represents his estimate of how much work is involved in the story under discussion. All estimates are kept private until each participant has chosen a card. At that time, all estimates are revealed and discussion can begin again.
Wikipedia on Planning Poker
Planning Poker in Detail
Sign up for Online Planning Poker
Order your own set of Planning Poker cards from Crisp, Sweden
Order your own set of Planning Poker cards from Nordija, Denmark
Order your own set of Planning Poker cards from Agile Hardware, USA
Order your own set of Planning Poker cards from Mountain Goat Software, USA
Order your own set of Planning Poker cards from Houston Inc., USA
Let’s say the team is working on some story and need to finish a task which is originally estimated to 4 days. Once the team starts working they continuously decrease the estimate until they reach 1. The task then remains on “1 day remaining” for several days – even though the team actually do work (and hard, too) on finishing the task. You ask the team what’s going on, why the task never reach 0, and the reply you get is “Well, things keep popping up that we didn’t think of which has to be done too in order to finish this task. We can’t finish the task unless we also handle those things.”. Let’s say you don’t only see this occasionally. You see it over and over again, Story after Story and Sprint after Sprint. [...]