Imagine you have a jar full of beads. Your job is to guess (estimate) how many beads there are, so you ask your team of bead experts. They hand the jar around and give widely different estimates. In the discussion that unfolds you learn about the density of different bead materials, the distribution of sizes in different bead mixes and the sound beads make in a jar.
When you open the jar you will know much more of what to expect than just the amount of beads, but “how many beads?” was the only question needed to start the conversation.
Estimates in software is not about scheduling tasks or defining velocity. “How big is this task?” is a shortcut to a discussion on scope, technical limitations and prerequisites.
We need to understand our options when prioritizing. The scope might be interpreted in different ways. Members of the team have relevant knowledge unique to them that changes the understanding of work required. All of this will show in an estimate of size.
Instead of taking all the beads out of the jar to sort them, we just ask how many they are. Then we keep the information it generates and throw out the estimate.
Comment on the blog!
Create a comment by emailing me.
I will then add the comment to the post.