- Give you an understanding of risk and unknowns.
- Quantify the known work.
- Be something that you can base a big decision on.
- Be refined as new information becomes available.
- Be a range with a 90% confidence interval.
In part 1 I explained how to account for risk and unknowns in your software estimation. In part 2 I explained how to quantify the work that is known. In the final post of this series I explain the last pieces needed to give an accurate software estimation.
Let's say we estimate project X and determine that it will take 2 developers 2 months to complete. After estimating project Y we know that it will take 2 developers 1 month to complete (or 1 developer 2 months). Finally, when estimating project Z we determine that it will take 1 person 1 month. We now have a starting point from which to determine, based on cost to build and return on investment, if there is an opportunity loss associated with starting project X before projects Y or Z.
Most software estimates will start out as a range. Typically larger projects will have a wider range. This is because there are always things we know we don't know about the project as well as things that we don't know that we don't know.
It is easier to reduce ambiguity with information we know we don't know because we know where to start. As you practice software estimation you'll start to learn the correct questions to ask to identify the information you don't know you don't know.
Identifying new information should result in refining your previous estimate. The more ambiguity you are able to remove the more accurate your software estimate can be. The goal should be to continually narrow the range of the estimate.
A confidence interval is a range of numbers from which we expect the real value to be contained. Having a good confidence interval allows us to determine the range of our estimate. This range can then be examined to validate our assumptions and to identify ambiguity.
For example, if I asked you to estimate how many marbles fit in a mason jar the actual number of marbles that would fit would be contained in your estimate. My 90% confidence interval may be 25 - 100 marbles. The actual number of marbles may be 87, in which case my interval contained the real value.
If you're interested in learning more about how to compute a confidence interval you should read How to Measure Anything by Douglas Hubbard.
I'll wrap up this post with some questions you can ask to identify and clarify ambiguity in your software estimates.
Identifying Opportunity Cost
Let's say we estimate project X and determine that it will take 2 developers 2 months to complete. After estimating project Y we know that it will take 2 developers 1 month to complete (or 1 developer 2 months). Finally, when estimating project Z we determine that it will take 1 person 1 month. We now have a starting point from which to determine, based on cost to build and return on investment, if there is an opportunity loss associated with starting project X before projects Y or Z.
Refining As New Information Becomes Available
Most software estimates will start out as a range. Typically larger projects will have a wider range. This is because there are always things we know we don't know about the project as well as things that we don't know that we don't know.
It is easier to reduce ambiguity with information we know we don't know because we know where to start. As you practice software estimation you'll start to learn the correct questions to ask to identify the information you don't know you don't know.
Identifying new information should result in refining your previous estimate. The more ambiguity you are able to remove the more accurate your software estimate can be. The goal should be to continually narrow the range of the estimate.
More Accurate When Accompanied By A Confidence Interval
A confidence interval is a range of numbers from which we expect the real value to be contained. Having a good confidence interval allows us to determine the range of our estimate. This range can then be examined to validate our assumptions and to identify ambiguity.
For example, if I asked you to estimate how many marbles fit in a mason jar the actual number of marbles that would fit would be contained in your estimate. My 90% confidence interval may be 25 - 100 marbles. The actual number of marbles may be 87, in which case my interval contained the real value.
If you're interested in learning more about how to compute a confidence interval you should read How to Measure Anything by Douglas Hubbard.
Identify And Clarify Ambiguity
I'll wrap up this post with some questions you can ask to identify and clarify ambiguity in your software estimates.
- What assumptions does your estimate rely on?
- What are the risks associated with your estimate? Identify the things that could cause your estimate to be wrong.
- What external dependencies does your project have? For example OS updates, product launches, planned outtages, SDK updates, etc.
- What data do you need? Is it already available in a consumable format?
- What services are required? Do they exist? Do they talk the correct protocol?
- Are there any User Interface (UI) or User Experience (UX) dependencies that need to be resolved?
No comments:
Post a Comment