The dream world of estimations

Do you commit to estimates? well, I don't.

Let's say you have a developer. Let us call him Joe. Joe is not the sharpest of developers. He's not bad, but he's not the best. During the sprint start, there is a party of planning poker held on a user story. Implement Donkilidoldi in the Windows application. Joe says it's a three. The other guys a one. They say it's really easy and go on about how easy it is. Well, thinks Joe. Perhaps it is.

The very next day, Joe starts with Donkilidoldi. And perhaps it was a one for one of the others. He can do it in a one. But it won't be a very nice solution. It will be dog ugly. "But they said it was a one, so perhaps is what they meant" Joe thinks. And how can he say that it is complicated when they said it was easy...

So, what was the end to this saga? Next month, another developer. Let us call her Linda, takes the task of making version 2 of Donkilidoldi. The estimate is a three, and that is of course based on the assumption that version 1 of Donkilidoldi was done as the fastest of the developers had thought. But this is not the case. So, Linda thinks: is THIS how it's done? Well, then I have to do this ugly workaround just to make it work. Because she only have a three to work on. And she feels really stupid having not read the check in e-mails properly to know how Donkilidoldi worked.

This is one easy way to create a technical debt. I don't believe in collective commitment to an estimate. What I can commit to is an estimate when I've started working with a task, and concentrated on just that task during that timespan. Joe could only commit to an estimate when he was given the responsibility. Linda when she saw first hand what she had to work with.

For more on this subject, read Serial Seb!