Refusal of preliminary estimates: what is the meaning of #NoEstimates
A couple of years ago the #NoEstimates hashtag appeared on Twitter. The purpose of its creation was a discussion about what is worth replacing the preliminary estimates of the cost and timing of the project. The very idea of ​​a project without such assessments sounds strange to most software developers, however, if you go deeper, you can find better sources of information.
When I first heard about #NoEstimates, it sounded weird, even heresy. How is a project possible without preliminary assessments? Isn't it obvious to anyone that they are the basis for planning, without which you can’t do anything?
')
In the next two years, this turned into a discussion topic, and I repeatedly thought and wrote about it. This article summarizes my attitude towards #NoEstimates and its real goals.
What is #NoEstimates?
I think the hashtag was intentionally provocative. But if you look at the site, it is clear that in fact the idea is not so categorical. The people who spawned the debate (Woody Zuill, Neil Killick and Vasco Duarte) say that it is about alternatives to preliminary assessments, and not just giving up on them.
However, this inevitably gave rise to objection and legitimate questions from project managers: “But how can we plan without it? Shouldn't a project customer paying for it know how much the project will cost and how much will it take to create? ”
These are very good questions.
Imagine that you hired someone to do repairs in the kitchen. You request a quote from him, and he says that everything will cost $ 20,000 and take four weeks. You know that he is mistaken. In practice, it will turn out twice as long and twice as expensive.
But if you already know this, why do you ask initially?
If you think “I need estimated values ​​for the work to be done,” stop it. If you had an infinite amount of time and money, it would have been done anyway.
We do not need preliminary estimates by themselves. But we crave them.
Why do we crave them?
We want them to make a decision. Based on them, we decide whether the project is worth it. If it is too expensive or takes too long, we can cancel it or postpone it. So, if we compare different estimates, we can choose the one that suits us best.
In addition, they help in planning. For example, if it is assumed that product development will take a year, then its marketing will begin a couple of months before the end of this year. And train salespeople will start in a month. Preliminary estimates give us these ideas, allowing you to plan more accurately.
Obviously, they are important: everyone wants to get them. But the nuance is that no one likes to provide them.
The problem with the preliminary estimates
Have you ever given a preliminary assessment, which “magically” turned into a commitment? This organizational overlay occurs very often, and inaccurate forecasts become deadlines, according to which the developer is evaluated.
Developers are smart, so do not fall into this trap twice. They make predictions with a margin, then the team adds time just in case, and then another boss strengthens to make sure. We can go from a few weeks to months, or even years.
And then everything is getting wrong. If we need an assessment in order to make a decision, then we do not have the numbers on the basis of which we must decide!
We are so smart that we have found a solution for this: if we learn more about the project, we get a more accurate idea (yes, sometimes it happens). If everyone agrees with the amount of work required, then there is no need for inventory. So we are going, we are discussing, we are meeting again, sometimes for weeks, in order to evaluate as precisely as possible what we are going to do. After a couple of months, we finally have a number on our hands. And for this couple of months, we spent hundreds of man-hours on estimates and calculations instead of actually creating a product.
There are many problems with the estimates. But the main thing is not even that.
Preliminary estimates do not really help.
I have never seen a project canceled because of them. If it was valuable enough, we would find a way to do it. But I saw how projects were postponed due to the fact that their value was uncertain. And it's nice to have several different options, but they all have no value, if at the time of the decision, they all equally do not trust. And show me the head of the project, which is so entrusted to my current forecast that in ten months you won’t ask me if you can really start marketing.
We want to get preliminary estimates for decision making and planning. But it seems they are not very useful tools for these tasks.
We do not trust forecasts, because we do them badly. We are biased, we are overly optimistic, we think that we know what we are talking about, and the project will spit. And then we are surprised every time. So when we meet with preliminary estimates, we are skeptical and right about that.
We also have a theoretical rationale for this. Steve McConnell introduced the world to the concepts of the Cone of Uncertainty twenty years ago. When we make a preliminary assessment of the project, we know the least about it. The more we progress in work, the more fog dissipates and forecasts are refined. But if the requirements change (and they always change), the cone opens again, and all assessments fly off the drain.
What do we really want?
We want to be right. We want to make the right decisions and feel confident about it. Estimates are tools for this, but rely only on them. Perhaps there is another source of information that can help us act correctly and confidently.
Neil Killick gives this example. You need to get somewhere by train. You can ask "when the train leaves?", And I will give a rough estimate, which helps to plan. But if I said “I won’t guess when I drive off, but I know for sure that they walk in ten minutes,” would this help to make a better decision?
With the appearance of new information, the accuracy of preliminary estimates suddenly becomes less significant.
What other types of information can help us?
If you look back, you can see other types of information on the basis of which decisions can be made.
Prioritization by value: if we estimate what value we get, and then compare with the estimated costs, we can make the best decision. Focusing on value, not value, means starting from where to invest. Planning methods such as calculating the cost of delay put emphasis on value, making it easy to compare projects and prioritize.
Difficulty rating: assess how much the project is similar to others and how much of the information about them applies to your team. Has a similar project been implemented before by your team? In your company? Or is it completely new? Answer this and see what your grades are worth. The Liz Keoh model for assessing complexity can put your assessments in context.
Collect data: the experience of the past allows you to predict more precisely than the inner voice. The speed with which the team is working on the project indicates how long it will be logical for such projects. However, this may not be applicable to other commands, technologies or areas, so be careful here.
Reduce variability: speed data is useful if projects are close in size. If something always takes three to four days, you can predict. If everything is very different, then you definitely cannot predict. The team should be able to measure equal intervals of work, and when they learn, it will be possible to predict where it is more reliable.
Assume that you know nothing: the former US Secretary of Defense cleverly reduced the categories of knowledge to “what we know, know this,” “what we don’t know” and “what we don’t know, what we don’t know.” For the first two categories, we make forecasts, and the third tears all our forecasts to shreds. The most important thing that we can assume is that we do not know anything and everything we know only assumptions.
Calculate your assumptions: our estimates are based on assumptions, and it is better to first discuss the assumptions, and then move on to the predictions based on them. When we make our assumptions known, a funny thing happens: they can be criticized, approved or crushed. The criticism that will have to be received is a rather modest payment for relying on assumptions divorced from reality.
Experiment: finally, is it worth taking everything out of your head? It may be worthwhile in practice to try to understand what we have to do. Instead of creating a plan based on our sucked from the finger, you can experimentally test many assumptions. We can plan a set of small, budgetary, not threatening to us in case of failure experiments, which will show which of the assumptions are true, and show the way to a successful product, rather than a painful failure.
There are projects made without any forecasts at all. But such an approach requires the environment to understand it. If your organization has not yet reached an understanding, try to teach the people around you to at least use alternatives as a complement to predictions, if not a substitute. Limit the time to calculate the estimates and instead take it to get quick feedback on assumptions.
When I started learning #NoEstimates, the idea seemed strange to me. Now the traditional approach seems strange to me. Although it is very easy to ask “How much it will cost,” I now almost automatically try to make decisions based less on assumptions and more on real information instead. It's more logical, isn't it?
When I first heard about #NoEstimates, it sounded weird, even heresy. How is a project possible without preliminary assessments? Isn't it obvious to anyone that they are the basis for planning, without which you can’t do anything?
')
In the next two years, this turned into a discussion topic, and I repeatedly thought and wrote about it. This article summarizes my attitude towards #NoEstimates and its real goals.
What is #NoEstimates?
I think the hashtag was intentionally provocative. But if you look at the site, it is clear that in fact the idea is not so categorical. The people who spawned the debate (Woody Zuill, Neil Killick and Vasco Duarte) say that it is about alternatives to preliminary assessments, and not just giving up on them.
However, this inevitably gave rise to objection and legitimate questions from project managers: “But how can we plan without it? Shouldn't a project customer paying for it know how much the project will cost and how much will it take to create? ”
These are very good questions.
Imagine that you hired someone to do repairs in the kitchen. You request a quote from him, and he says that everything will cost $ 20,000 and take four weeks. You know that he is mistaken. In practice, it will turn out twice as long and twice as expensive.
But if you already know this, why do you ask initially?
If you think “I need estimated values ​​for the work to be done,” stop it. If you had an infinite amount of time and money, it would have been done anyway.
We do not need preliminary estimates by themselves. But we crave them.
Why do we crave them?
We want them to make a decision. Based on them, we decide whether the project is worth it. If it is too expensive or takes too long, we can cancel it or postpone it. So, if we compare different estimates, we can choose the one that suits us best.
In addition, they help in planning. For example, if it is assumed that product development will take a year, then its marketing will begin a couple of months before the end of this year. And train salespeople will start in a month. Preliminary estimates give us these ideas, allowing you to plan more accurately.
Obviously, they are important: everyone wants to get them. But the nuance is that no one likes to provide them.
The problem with the preliminary estimates
Have you ever given a preliminary assessment, which “magically” turned into a commitment? This organizational overlay occurs very often, and inaccurate forecasts become deadlines, according to which the developer is evaluated.
Developers are smart, so do not fall into this trap twice. They make predictions with a margin, then the team adds time just in case, and then another boss strengthens to make sure. We can go from a few weeks to months, or even years.
And then everything is getting wrong. If we need an assessment in order to make a decision, then we do not have the numbers on the basis of which we must decide!
We are so smart that we have found a solution for this: if we learn more about the project, we get a more accurate idea (yes, sometimes it happens). If everyone agrees with the amount of work required, then there is no need for inventory. So we are going, we are discussing, we are meeting again, sometimes for weeks, in order to evaluate as precisely as possible what we are going to do. After a couple of months, we finally have a number on our hands. And for this couple of months, we spent hundreds of man-hours on estimates and calculations instead of actually creating a product.
There are many problems with the estimates. But the main thing is not even that.
Preliminary estimates do not really help.
I have never seen a project canceled because of them. If it was valuable enough, we would find a way to do it. But I saw how projects were postponed due to the fact that their value was uncertain. And it's nice to have several different options, but they all have no value, if at the time of the decision, they all equally do not trust. And show me the head of the project, which is so entrusted to my current forecast that in ten months you won’t ask me if you can really start marketing.
We want to get preliminary estimates for decision making and planning. But it seems they are not very useful tools for these tasks.
We do not trust forecasts, because we do them badly. We are biased, we are overly optimistic, we think that we know what we are talking about, and the project will spit. And then we are surprised every time. So when we meet with preliminary estimates, we are skeptical and right about that.
We also have a theoretical rationale for this. Steve McConnell introduced the world to the concepts of the Cone of Uncertainty twenty years ago. When we make a preliminary assessment of the project, we know the least about it. The more we progress in work, the more fog dissipates and forecasts are refined. But if the requirements change (and they always change), the cone opens again, and all assessments fly off the drain.
What do we really want?
We want to be right. We want to make the right decisions and feel confident about it. Estimates are tools for this, but rely only on them. Perhaps there is another source of information that can help us act correctly and confidently.
Neil Killick gives this example. You need to get somewhere by train. You can ask "when the train leaves?", And I will give a rough estimate, which helps to plan. But if I said “I won’t guess when I drive off, but I know for sure that they walk in ten minutes,” would this help to make a better decision?
With the appearance of new information, the accuracy of preliminary estimates suddenly becomes less significant.
What other types of information can help us?
If you look back, you can see other types of information on the basis of which decisions can be made.
Prioritization by value: if we estimate what value we get, and then compare with the estimated costs, we can make the best decision. Focusing on value, not value, means starting from where to invest. Planning methods such as calculating the cost of delay put emphasis on value, making it easy to compare projects and prioritize.
Difficulty rating: assess how much the project is similar to others and how much of the information about them applies to your team. Has a similar project been implemented before by your team? In your company? Or is it completely new? Answer this and see what your grades are worth. The Liz Keoh model for assessing complexity can put your assessments in context.
Collect data: the experience of the past allows you to predict more precisely than the inner voice. The speed with which the team is working on the project indicates how long it will be logical for such projects. However, this may not be applicable to other commands, technologies or areas, so be careful here.
Reduce variability: speed data is useful if projects are close in size. If something always takes three to four days, you can predict. If everything is very different, then you definitely cannot predict. The team should be able to measure equal intervals of work, and when they learn, it will be possible to predict where it is more reliable.
Assume that you know nothing: the former US Secretary of Defense cleverly reduced the categories of knowledge to “what we know, know this,” “what we don’t know” and “what we don’t know, what we don’t know.” For the first two categories, we make forecasts, and the third tears all our forecasts to shreds. The most important thing that we can assume is that we do not know anything and everything we know only assumptions.
Calculate your assumptions: our estimates are based on assumptions, and it is better to first discuss the assumptions, and then move on to the predictions based on them. When we make our assumptions known, a funny thing happens: they can be criticized, approved or crushed. The criticism that will have to be received is a rather modest payment for relying on assumptions divorced from reality.
Experiment: finally, is it worth taking everything out of your head? It may be worthwhile in practice to try to understand what we have to do. Instead of creating a plan based on our sucked from the finger, you can experimentally test many assumptions. We can plan a set of small, budgetary, not threatening to us in case of failure experiments, which will show which of the assumptions are true, and show the way to a successful product, rather than a painful failure.
There are projects made without any forecasts at all. But such an approach requires the environment to understand it. If your organization has not yet reached an understanding, try to teach the people around you to at least use alternatives as a complement to predictions, if not a substitute. Limit the time to calculate the estimates and instead take it to get quick feedback on assumptions.
When I started learning #NoEstimates, the idea seemed strange to me. Now the traditional approach seems strange to me. Although it is very easy to ask “How much it will cost,” I now almost automatically try to make decisions based less on assumptions and more on real information instead. It's more logical, isn't it?
Source: https://habr.com/ru/post/286924/
All Articles