| XP: Real-world experiment with Hours instead of points
|
|
11 Apr 07 |
Manuel Klimek posted his insights to the XP-list.
Hi,
we're currently implementing some the XP concepts when we can see the
reason for using a concept. Mostly this is due to some problems we
identify. I'm not a consultant, but integrated into a development
team, perhaps that allows me to see things from a different
perspective.
I found that people dislike "guessing" effort in time, because they
feel bad if estimated ideal time is small compared to actual time.
This can lead to the following problems:
- overcommitment (but this time I'll do it in 2 days! really!)
- undercommitment (if I guess a lot too much, I feel better if I'm wrong)
- artificial pressure (I guessed 2 days, so I need to do it in 2 days,
let's not do refactoring now)
- demotivation (being wrong makes me feel bad)
- problems with communication to product management ("but you said
you'll do it in 2 days, now it took already 5!" - "but I said it's
ideal time!" - "than tell us the actual time it will take the next
time!" - "but I can't do that" etc)
Using points solved this. Perhaps explaining to the developers that
they have to accept that ideal time has nothing to do with actual time
and that they should not worry too much about correctness of single
guesses and explaining to product management that there are different
time estimations (some in ideal time and some in actual time) would
have solved the issue, too, but simply using points is clearer, since
you make the distinction explicit if you communicate about effort.
If I tell to product management that this item has size 3 and they ask
me how long it'll take, then I tell them that if they include it in
the current iteration they'll have it at the time the current
iteration finishes.
All this is less communication effort for me and thus increases ROI
because I can work on code instead of nitpicking on the concept of
time :-)
Cheers,
Manuel
Skiing in Garmisch :-).
|
