I bought a book around 6 months ago called Software Estimation: The Black Art Demystified. It's one of those types of book along with Code Complete which should be on every developers reading list, and by reading list, I mean read it once per year, every just a refresher.
So the book was parked after around 80 pages shortly before Emily arrived (our new baby), and now she's here the book is gathering dust.
Two articles appeared on my aggregator recently. One from Joel Spolsky on Evidence Based Scheduling and one from Jeff Atwood on Planning Poker, partially responding to Joel's post.
Both posts are very well written and are worth a read. They rekindled my interest in this topic, sort of the point of them I suspect!
As the Black Art book explains, everyone thinks they can estimate. While influencing people's decisions can prove hard, actually changing their approach to estimating I find is even harder.
A few techniques I wonder about using:
- Planning Poker. I love the idea of this, it seems a smart and tidy approach to reach a good consensus. However the flaw here is you need a set of equally able and open minded people who actually listen, otherwise failure is on the cards. I feel a slightly diluted version of this will work well to turn the tide.
- Track estimate against actual. I think of all of the suggestions, this is the easiest to deliver and shows exactly how good your estimates are. The FogBuzz product from Joel's company uses this to good effect.
I've set myself a target to read this book cover to cover within the next 2 months and hope to reflect on it here.
What do you think? How do you approach estimating in your workplace?
No comments:
Post a Comment