Skip to main content
Commonmark migration
Source Link

Estimates are not single numbers. An estimate is a range that has a high end, a low end and a confidence. With the initial question of "how long will it take you" an estimate is not "it will take me 14 hours" but rather "it will take me between 10 and 18 hours".

As you refine the process, you can get a tighter and tighter range on the estimate

[![][1]][1]
(source: construx.com)

Note that this shows the variability of the estimate, not that "it converges at the average". An estimate may start out at "it will take me 10 to 18 hours" and then be "it will take me 14 to 18 hours" and then "it will take me 16 to 18 hours" as you get further along in the task.

One of the most often cited books in estimation is Software Estimation: Demystifying the Black Art by Steve McConnell.

Start out with a very wide estimate that has the best case and the worst case. Then shortly into the research, do another estimate, and then another and another. Don't make a commitment as to when it will be done with one number and then try to make it.

There are a number of different techniques for generating an estimate. Use historical data from past estimates. Try to get an idea of how big it is, the complexity and work from that (the list goes on, there's an entire book written about this). [1]: https://i.sstatic.net/RKrRF.jpg

Estimates are not single numbers. An estimate is a range that has a high end, a low end and a confidence. With the initial question of "how long will it take you" an estimate is not "it will take me 14 hours" but rather "it will take me between 10 and 18 hours".

As you refine the process, you can get a tighter and tighter range on the estimate

[![][1]][1]
(source: construx.com)

Note that this shows the variability of the estimate, not that "it converges at the average". An estimate may start out at "it will take me 10 to 18 hours" and then be "it will take me 14 to 18 hours" and then "it will take me 16 to 18 hours" as you get further along in the task.

One of the most often cited books in estimation is Software Estimation: Demystifying the Black Art by Steve McConnell.

Start out with a very wide estimate that has the best case and the worst case. Then shortly into the research, do another estimate, and then another and another. Don't make a commitment as to when it will be done with one number and then try to make it.

There are a number of different techniques for generating an estimate. Use historical data from past estimates. Try to get an idea of how big it is, the complexity and work from that (the list goes on, there's an entire book written about this). [1]: https://i.sstatic.net/RKrRF.jpg

Estimates are not single numbers. An estimate is a range that has a high end, a low end and a confidence. With the initial question of "how long will it take you" an estimate is not "it will take me 14 hours" but rather "it will take me between 10 and 18 hours".

As you refine the process, you can get a tighter and tighter range on the estimate


(source: construx.com)

Note that this shows the variability of the estimate, not that "it converges at the average". An estimate may start out at "it will take me 10 to 18 hours" and then be "it will take me 14 to 18 hours" and then "it will take me 16 to 18 hours" as you get further along in the task.

One of the most often cited books in estimation is Software Estimation: Demystifying the Black Art by Steve McConnell.

Start out with a very wide estimate that has the best case and the worst case. Then shortly into the research, do another estimate, and then another and another. Don't make a commitment as to when it will be done with one number and then try to make it.

There are a number of different techniques for generating an estimate. Use historical data from past estimates. Try to get an idea of how big it is, the complexity and work from that (the list goes on, there's an entire book written about this).

broken image fixed (click 'side-by-side' to see the difference); for more info, see https://gist.github.com/Glorfindel83/9d954d34385d2ac2597bbe864466259f
Source Link
Glorfindel
  • 3.2k
  • 6
  • 26
  • 33

Estimates are not single numbers. An estimate is a range that has a high end, a low end and a confidence. With the initial question of "how long will it take you" an estimate is not "it will take me 14 hours" but rather "it will take me between 10 and 18 hours".

As you refine the process, you can get a tighter and tighter range on the estimate

http://www.construx.com/uploadedImages/Construx/Construx_Content/Resources/Books/Cone01.jpg

[![][1]][1]
(source: construx.com)

Note that this shows the variability of the estimate, not that "it converges at the average". An estimate may start out at "it will take me 10 to 18 hours" and then be "it will take me 14 to 18 hours" and then "it will take me 16 to 18 hours" as you get further along in the task.

One of the most often cited books in estimation is Software Estimation: Demystifying the Black Art by Steve McConnell.

Start out with a very wide estimate that has the best case and the worst case. Then shortly into the research, do another estimate, and then another and another. Don't make a commitment as to when it will be done with one number and then try to make it.

There are a number of different techniques for generating an estimate. Use historical data from past estimates. Try to get an idea of how big it is, the complexity and work from that (the list goes on, there's an entire book written about this). [1]: https://i.sstatic.net/RKrRF.jpg

Estimates are not single numbers. An estimate is a range that has a high end, a low end and a confidence. With the initial question of "how long will it take you" an estimate is not "it will take me 14 hours" but rather "it will take me between 10 and 18 hours".

As you refine the process, you can get a tighter and tighter range on the estimate

http://www.construx.com/uploadedImages/Construx/Construx_Content/Resources/Books/Cone01.jpg

Note that this shows the variability of the estimate, not that "it converges at the average". An estimate may start out at "it will take me 10 to 18 hours" and then be "it will take me 14 to 18 hours" and then "it will take me 16 to 18 hours" as you get further along in the task.

One of the most often cited books in estimation is Software Estimation: Demystifying the Black Art by Steve McConnell.

Start out with a very wide estimate that has the best case and the worst case. Then shortly into the research, do another estimate, and then another and another. Don't make a commitment as to when it will be done with one number and then try to make it.

There are a number of different techniques for generating an estimate. Use historical data from past estimates. Try to get an idea of how big it is, the complexity and work from that (the list goes on, there's an entire book written about this).

Estimates are not single numbers. An estimate is a range that has a high end, a low end and a confidence. With the initial question of "how long will it take you" an estimate is not "it will take me 14 hours" but rather "it will take me between 10 and 18 hours".

As you refine the process, you can get a tighter and tighter range on the estimate

[![][1]][1]
(source: construx.com)

Note that this shows the variability of the estimate, not that "it converges at the average". An estimate may start out at "it will take me 10 to 18 hours" and then be "it will take me 14 to 18 hours" and then "it will take me 16 to 18 hours" as you get further along in the task.

One of the most often cited books in estimation is Software Estimation: Demystifying the Black Art by Steve McConnell.

Start out with a very wide estimate that has the best case and the worst case. Then shortly into the research, do another estimate, and then another and another. Don't make a commitment as to when it will be done with one number and then try to make it.

There are a number of different techniques for generating an estimate. Use historical data from past estimates. Try to get an idea of how big it is, the complexity and work from that (the list goes on, there's an entire book written about this). [1]: https://i.sstatic.net/RKrRF.jpg

Source Link
user40980
user40980

Estimates are not single numbers. An estimate is a range that has a high end, a low end and a confidence. With the initial question of "how long will it take you" an estimate is not "it will take me 14 hours" but rather "it will take me between 10 and 18 hours".

As you refine the process, you can get a tighter and tighter range on the estimate

http://www.construx.com/uploadedImages/Construx/Construx_Content/Resources/Books/Cone01.jpg

Note that this shows the variability of the estimate, not that "it converges at the average". An estimate may start out at "it will take me 10 to 18 hours" and then be "it will take me 14 to 18 hours" and then "it will take me 16 to 18 hours" as you get further along in the task.

One of the most often cited books in estimation is Software Estimation: Demystifying the Black Art by Steve McConnell.

Start out with a very wide estimate that has the best case and the worst case. Then shortly into the research, do another estimate, and then another and another. Don't make a commitment as to when it will be done with one number and then try to make it.

There are a number of different techniques for generating an estimate. Use historical data from past estimates. Try to get an idea of how big it is, the complexity and work from that (the list goes on, there's an entire book written about this).