Comments on: Where Did You Get That Estimate? http://tynerblain.com/blog/2006/04/28/where-did-you-get-that-estimate/ Software product success. Sun, 12 Feb 2012 19:10:25 +0000 hourly 1 http://wordpress.org/?v=3.0.4 By: Scott Sehlhorst http://tynerblain.com/blog/2006/04/28/where-did-you-get-that-estimate/comment-page-1/#comment-365988 Scott Sehlhorst Wed, 07 May 2008 02:41:57 +0000 http://tynerblain.com/blog/2006/04/28/where-did-you-get-that-estimate/#comment-365988 Juan Carlos, thanks for the comment and welcome to Tyner Blain! You're exactly right - having multiple forms of estimation for any given task gives you greater confidence (when they all reach similar conclusions) in your estimates. Errors with one approach tend to be offset by errors introduced by the others. Thanks again! Juan Carlos, thanks for the comment and welcome to Tyner Blain!

You’re exactly right – having multiple forms of estimation for any given task gives you greater confidence (when they all reach similar conclusions) in your estimates. Errors with one approach tend to be offset by errors introduced by the others.

Thanks again!

]]> By: Juan Carlos http://tynerblain.com/blog/2006/04/28/where-did-you-get-that-estimate/comment-page-1/#comment-365699 Juan Carlos Tue, 06 May 2008 18:54:31 +0000 http://tynerblain.com/blog/2006/04/28/where-did-you-get-that-estimate/#comment-365699 You are right that no all estimation tecniques are good for all projects. However use a ONLY estimation tecnique to see the future is not a good practice. If you want to know the future, you need differentes perspectives, for example you can use 1. Expert Judgement 2. Analogy 3. FP 4. UCPS And with this scenario you can merge ( get a central point) and get the "real future". Also, that you say, We deliver software incrementally, so we can estimate incrementally. Remeber uncertain cone http://www.construx.com/Page.aspx?hid=1648. Yer I know that our clients dont like it, but its no necesary tell them this, but this estimation can use it to project control. Have a nice day- You are right that no all estimation tecniques are good for all projects. However use a ONLY estimation tecnique to see the future is not a good practice.
If you want to know the future, you need differentes perspectives, for example you can use
1. Expert Judgement
2. Analogy
3. FP
4. UCPS

And with this scenario you can merge ( get a central point) and get the “real future”.

Also, that you say, We deliver software incrementally, so we can estimate incrementally. Remeber uncertain cone http://www.construx.com/Page.aspx?hid=1648. Yer I know that our clients dont like it, but its no necesary tell them this, but this estimation can use it to project control.

Have a nice day-

]]> By: Scott Sehlhorst http://tynerblain.com/blog/2006/04/28/where-did-you-get-that-estimate/comment-page-1/#comment-1625 Scott Sehlhorst Mon, 01 May 2006 12:55:14 +0000 http://tynerblain.com/blog/2006/04/28/where-did-you-get-that-estimate/#comment-1625 Bikram, thanks very much for the kind words, and for reading here! You make a great point about improvement over time. My experience has been that _only_ a post-mortem on estimates can lead to improved estimation skills. The person who created the estimates tracks actual time spent, and then reconciles it. On one project where I lead 5 people through about a dozen three week timeboxes, we had an interesting effect - people began beating their estimates consistently in the later cycles of the project. The estimates were a combination of 'by analogy' and 'expert judgement'. The developers were not trying to improve their estimation skills during the project, and their estimates were consistent. I believe that the architectural decisions at the beginning of the project made their work progressively easier to accomplish, allowing them to beat estimates. It may be that they simply became more adept in the domain of this particular project. Thanks again, Scott Bikram, thanks very much for the kind words, and for reading here!

You make a great point about improvement over time. My experience has been that _only_ a post-mortem on estimates can lead to improved estimation skills. The person who created the estimates tracks actual time spent, and then reconciles it.

On one project where I lead 5 people through about a dozen three week timeboxes, we had an interesting effect – people began beating their estimates consistently in the later cycles of the project.

The estimates were a combination of ‘by analogy’ and ‘expert judgement’. The developers were not trying to improve their estimation skills during the project, and their estimates were consistent.

I believe that the architectural decisions at the beginning of the project made their work progressively easier to accomplish, allowing them to beat estimates. It may be that they simply became more adept in the domain of this particular project.

Thanks again,
Scott

]]> By: Bikram Kumar Gupta http://tynerblain.com/blog/2006/04/28/where-did-you-get-that-estimate/comment-page-1/#comment-1593 Bikram Kumar Gupta Mon, 01 May 2006 03:42:04 +0000 http://tynerblain.com/blog/2006/04/28/where-did-you-get-that-estimate/#comment-1593 Great post, Indeed!I have recently started reading all your posts in the archives as well and they make an excellent learning database. I would like to add something more to this post. How does "Estimate by analogy" ensure that we improve in software delivery every time? Possibly a combination of "Estimate by analogy" and "Use expert judgement" together can bring good results. In embedded systems code, I have seen (in lesser samples) the estimates to be badly beaten whenever algorithm estimates were prepared with good amount of effort. We can not discount the fact the Software estimation is a difficult skill to master and is also very much a function of people who will implement the software. Great post, Indeed!I have recently started reading all your posts in the archives as well and they make an excellent learning database. I would like to add something more to this post.

How does “Estimate by analogy” ensure that we improve in software delivery every time? Possibly a combination of “Estimate by analogy” and “Use expert judgement” together can bring good results. In embedded systems code, I have seen (in lesser samples) the estimates to be badly beaten whenever algorithm estimates were prepared with good amount of effort.

We can not discount the fact the Software estimation is a difficult skill to master and is also very much a function of people who will implement the software.

]]> By: Scott Sehlhorst http://tynerblain.com/blog/2006/04/28/where-did-you-get-that-estimate/comment-page-1/#comment-1529 Scott Sehlhorst Sat, 29 Apr 2006 16:59:29 +0000 http://tynerblain.com/blog/2006/04/28/where-did-you-get-that-estimate/#comment-1529 Received the following comment via email - thanks, Ed! "Should you include the PURPOSE of the estimate. When I did estimates, the purpose for which they were intended predetermined how thorough they were. Was it for conceptualizing the project, budgeting, capitalization, project approval, scheduling resources... " Received the following comment via email – thanks, Ed!

“Should you include the PURPOSE of the estimate. When I did estimates, the purpose for which they were intended predetermined how thorough they were. Was it for conceptualizing the project, budgeting, capitalization, project approval, scheduling resources… “

]]>