The point of estimates
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.
Offer
SAMMAN TECHNICAL TRAINING
Send your team to a course and some of them will remember part of it. Use the Samman method and they will apply what they learn from day one.
Book a meeting if you want to talk to me about agile methodology, to explore how I might help your team. I offer this for free, since I rather talk tech than do sales pitches. Let's explore if I can help you, by trying to solve your problems from the start.
Comment on the blog!
Create a comment by emailing me.
Open an email to start writing.I will then add the comment to the post.