We don't do that anymore.
It turns out that agile teams, once they've established a reputation, don't need a lot of estimation skill and many teams around the world operate happily without making estimates at all, since they always work on the thinnest slice of the most important feature at any point in time.
Now that I'm a greybeard programmer, I've come to believe five somewhat-controversial things about estimating.
Highly accurate estimating does not make your customers successful.
I'm always concerned about wasting a lot of time and effort (ie generating waste) in order to become good at something that does not make my customers more successful.
If I reduce the standard deviation of my estimates by half, it doesn't mean that my eLearning students will be any more capable of learning or that the materials are any more clear.
How much of my time is well-spent not helping my customer?
Regardless of whether you estimate 200% high or only 25% of the actual time you need, the same amount of work is going to be done this week.
Every software development group has to do with planning and estimating and budgeting for some period of time (annually, semi-annually, quarterly, etc). We have to provide some estimates to make that happen, but very few groups are actually doing the work they had planned a half-year or an entire year ago.
Again, it doesn't have to be exactly right, it just has to be credible enough to acquire appropriate resources for getting the job done.
The cone of uncertainty tells us that we know more about the time and cost of a feature after we've finished it than before we start. When we are just proposing a new feature, we have the least knowledge we will ever have about how we will do the work.
We are unsure of the skills we may need to develop, the topics we may have to learn, unaware of many of the issues that may arrive in implementation, and entirely unaware of the events that may distract us from the work.
The problem comes when people believe that the promise is the latest possible date that the product/project will be done, but they have argued for the soonest date with a non-zero chance of completion.
Since work we must do further in the future are so uncertain, we recognize that we can't safely estimate those jobs now. So we add time. This is reflected in the use of fibonacci numbers for estimates, because size (and distance in time) magnifies the risk. Higher risk = higher estimates.
It just makes sense that we do not underestimate future work, since it is always easier to add more work later than it is to negotiate features out of a promise that has been made.
The other advantage of assigning larger numbers is that it suggests that the story/feature might need to be split into smaller, simpler, more obviously implementable pieces.
Teams can do five size-two stories in a shorter period than they can do two size-five stories. Smaller jobs are less likely to expand or have hidden complexities. It pays us to keep our estimated units as small as possible.
Even though estimating can't be really excellent, and it doesn't really matter, and it's done at the wrong time, we often have to estimate (at least roughly) anyway.
We find there is a social effect to underestimating that is painful. The social effect for overestimating a little is pleasant, but for overestimating a lot it can be equally painful.
So we fall back on two observations from Estimating Software Projects:
Being safe, and not being too precise, seems to help when estimates must be produced. Considering how iffy estimates are, it might be better if you can change the way you work to not use estimates at all, or at least to not depend on them.
If I reduce the standard deviation of my estimates by half, it doesn't mean that my eLearning students will be any more capable of learning or that the materials are any more clear.
How much of my time is well-spent not helping my customer?
Estimating doesn't really matter (for production).
Regardless of whether you estimate 200% high or only 25% of the actual time you need, the same amount of work is going to be done this week.
Every software development group has to do with planning and estimating and budgeting for some period of time (annually, semi-annually, quarterly, etc). We have to provide some estimates to make that happen, but very few groups are actually doing the work they had planned a half-year or an entire year ago.
Again, it doesn't have to be exactly right, it just has to be credible enough to acquire appropriate resources for getting the job done.
Estimating is done at the wrong time.
The cone of uncertainty tells us that we know more about the time and cost of a feature after we've finished it than before we start. When we are just proposing a new feature, we have the least knowledge we will ever have about how we will do the work.
We are unsure of the skills we may need to develop, the topics we may have to learn, unaware of many of the issues that may arrive in implementation, and entirely unaware of the events that may distract us from the work.
The problem comes when people believe that the promise is the latest possible date that the product/project will be done, but they have argued for the soonest date with a non-zero chance of completion.
Further = larger.
Since work we must do further in the future are so uncertain, we recognize that we can't safely estimate those jobs now. So we add time. This is reflected in the use of fibonacci numbers for estimates, because size (and distance in time) magnifies the risk. Higher risk = higher estimates.
It just makes sense that we do not underestimate future work, since it is always easier to add more work later than it is to negotiate features out of a promise that has been made.
The other advantage of assigning larger numbers is that it suggests that the story/feature might need to be split into smaller, simpler, more obviously implementable pieces.
Teams can do five size-two stories in a shorter period than they can do two size-five stories. Smaller jobs are less likely to expand or have hidden complexities. It pays us to keep our estimated units as small as possible.
It pays to be safe.
Even though estimating can't be really excellent, and it doesn't really matter, and it's done at the wrong time, we often have to estimate (at least roughly) anyway.
We find there is a social effect to underestimating that is painful. The social effect for overestimating a little is pleasant, but for overestimating a lot it can be equally painful.
So we fall back on two observations from Estimating Software Projects:
- The shortest period with a non-zero chance of success is not an estimate.
- A good estimate is as likely to be short as long.
Being safe, and not being too precise, seems to help when estimates must be produced. Considering how iffy estimates are, it might be better if you can change the way you work to not use estimates at all, or at least to not depend on them.
No comments:
Post a Comment