Tasks hours vs story points
- an organisation i know (drenched in waterfall) are having a pretty tough time getting their heads round story points.
they have *ALWAYS* used man-days and boy-hours(ahem, politically incorrect I know) and points just don't make sense.
after trying to enlighten them with the value of points and that they are at most as bad a measure as man-days for estimation, I took a different tack (one I made up on the fly )
they struggled (mostly) with estimating stories in points but they could (comfortably) break stories down into tasks and come up with ideal task hours. They could also calculate their team capacity in hours.
Here is the interesting thing -
their task hour estimates were alot more accurate and subject to revision than their points.
Also coming out of a sprint, they now had 2 metrics of value they could use - points and ideal hour velocity! How cool!!
So they can say we have a velocity of 200 hours (ahem, which may as well be points!) or 45 points.
So the moral of the story is , don't get hung up on the units.
What experiences do you have around this subject...(answers on a large postcard).
- Hello, Ryan. On Thursday, April 2, 2009, at 8:29:25 AM, you wrote:
> I have seen first hand what happens when execs get ahold of teamYes. The best driver in the world won't get around the track in 1/2
> velocity and get fixated on making that number higher, saying things
> like, "We can make our release with all the features promised if we
> can just get our velocity up to 70 points per iteration". While we
> should all be challenged to do better each sprint, wanting/wishing/
> hoping for a 50% improvement in velocity is unrealistic. Velocity is
> what it is.
the time of the average driver. Whatever level of performance a team
has, they'll likely improve by percentages, not by multiples.
Demanding such changes is almost certainly going to be harmful.
> But my larger point is this: I bet 90% of the agile teams today spendYes. Surely the relative value of stories is at least 10x, and so is
> more time and energy on measuring and managing velocity than
> measuring and managing the value of their work. I would say most
> agile teams I see (and read about) are overly focused on building the
> thing right and under focused on building the right thing. You need
> to do both, but current agile thinking focuses much more attention on
> the former and far too little on the latter, which is a shame.
the cost. So there are things to do that cost 1 and are worth 100,
while others cost 100 and are worth 1. The difference due to choice
You are to act in the light of experience as guided by intelligence.
-- Nero Wolfe