Actual Gummi Bears For Estimation

Problem:

You need a unit for estimating the complexity of a task in a project, something more descriptive, yet more abstract, than "ideal time to completion". Ideally you'd like a unit of complexity rather than time, because programmers are not automata, and work at different rates due to any number of factors BeyondYourControl?.

Context:

The PointyHairedBoss can't grok why a three-IdealEngineeringDay?-project isn't routinely completed in three days. You need to be able to provide more accurate estimates than CountTheHands in order to satisfy the PowersThatBe. You know approximately what LoadFactor your team can expect to maintain over the next little while, but simply aren't that good at estimating task size yet.

Forces:

Solution:

Each programmer gets a bag of real, physical gummi bears at the computer, to munch on while programming. The contents are counted out before and after a programming session. Programmers should be instructed to eat them at at least a certain "baseline" rate representing work done while motivated and yet not required to think - say one per fifteen minutes of perfectly InTheGroove? work - but without an upper limit. But a programmer who notices a sharp increase in his/her own (or partner's, in the case of PairProgramming) GummiBearsOfComplexity intake should treat this as a ThoughtSmell?, and step away to think about the task at hand (or switch roles).

Resulting Context:

Each programmer develops his/her own metric for task complexity - based on past history, s/he can expect to "eat X many gummi bears" while completing the next task, following the usual practice; based on current load conditions, s/he can then translate that into a time estimate if need be.

Drawbacks:

Known Uses: None yet? Does anyone out there HaveThisPattern? I would have thought this was how the idea originally came about. No?

Related Patterns: Hmm ...

-- KarlKnechtel


CategoryPattern


EditText of this page (last edited June 22, 2007) or FindPage with title or text search