Comments on: Separate Estimating from Committing http://blog.mountaingoatsoftware.com/separate-estimating-from-committing Succeeding With Agile® Fri, 10 Feb 2012 03:51:54 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Mike Cohn http://blog.mountaingoatsoftware.com/separate-estimating-from-committing/comment-page-1#comment-293383 Mike Cohn Thu, 10 Nov 2011 05:22:26 +0000 http://blog.mountaingoatsoftware.com/?p=544#comment-293383 Hi Biju-- No, I don't think a programmer who says "18 hours" in a sprint needs to have that be a commitment rather than an estimate. An alternative is that the programmer and tester talk frequently during the sprint so that any delays (or early finishes) can be adjusted for. For more on that see this article about <a href="http://www.mountaingoatsoftware.com/articles/44-agile-teamwork" rel="nofollow">minimizing problems due to handoffs</a>. Hi Biju–
No, I don’t think a programmer who says “18 hours” in a sprint needs to have that be a commitment rather than an estimate. An alternative is that the programmer and tester talk frequently during the sprint so that any delays (or early finishes) can be adjusted for. For more on that see this article about minimizing problems due to handoffs.

]]> By: Biju http://blog.mountaingoatsoftware.com/separate-estimating-from-committing/comment-page-1#comment-293374 Biju Thu, 10 Nov 2011 04:55:05 +0000 http://blog.mountaingoatsoftware.com/?p=544#comment-293374 Hi Mike, Came across this bit in your site pretty late! I understand the practical 'gap' that can occur between an estimate and commitment for longer time windows (by longer, i include even 4-5 sprints). However, I am interested to know how this difference plays out within a sprint. For example, in my sprint teams, we have a separate testing (QA)group. So, while planning to release something in 2 weeks, it becomes important to also plan when a feature (in parts maybe) reach the QA group for testing. No point in the developer having capacity within the 2 weeks and taking entire 2 weeks to develop it. It needs to be done by a certain date, for it to be tested and signed off. In this case, just an estimate (say overall 18 hours) for a story is not enough. It has to be a commitment, because a slip has ripple effects. Thoughts? Hi Mike,

Came across this bit in your site pretty late! I understand the practical ‘gap’ that can occur between an estimate and commitment for longer time windows (by longer, i include even 4-5 sprints). However, I am interested to know how this difference plays out within a sprint. For example, in my sprint teams, we have a separate testing (QA)group. So, while planning to release something in 2 weeks, it becomes important to also plan when a feature (in parts maybe) reach the QA group for testing. No point in the developer having capacity within the 2 weeks and taking entire 2 weeks to develop it. It needs to be done by a certain date, for it to be tested and signed off. In this case, just an estimate (say overall 18 hours) for a story is not enough. It has to be a commitment, because a slip has ripple effects. Thoughts?

]]> By: Markus Tamm » Blog Archive » Links 22.02.2010 http://blog.mountaingoatsoftware.com/separate-estimating-from-committing/comment-page-1#comment-66576 Markus Tamm » Blog Archive » Links 22.02.2010 Mon, 22 Feb 2010 08:39:46 +0000 http://blog.mountaingoatsoftware.com/?p=544#comment-66576 [...] Separate Estimating from Committing [...] [...] Separate Estimating from Committing [...]

]]> By: LaSSar2000 Blog » Blog Archive » Separate Estimating from Committing | Mike Cohn’s Blog – Succeeding With Agile® http://blog.mountaingoatsoftware.com/separate-estimating-from-committing/comment-page-1#comment-65796 LaSSar2000 Blog » Blog Archive » Separate Estimating from Committing | Mike Cohn’s Blog – Succeeding With Agile® Fri, 12 Feb 2010 16:50:49 +0000 http://blog.mountaingoatsoftware.com/?p=544#comment-65796 [...] Separate Estimating from Committing | Mike Cohn’s Blog – Succeeding With Agile®. [...] [...] Separate Estimating from Committing | Mike Cohn’s Blog – Succeeding With Agile®. [...]

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/separate-estimating-from-committing/comment-page-1#comment-65736 Mike Cohn Thu, 11 Feb 2010 14:18:31 +0000 http://blog.mountaingoatsoftware.com/?p=544#comment-65736 Hi Heiko-- Of course I would be frustrated if my mechanic initially told me $200 and later charged me $800. But let's look at a couple of key assumptions. A key premise for me is that estimates need to *always* be accurate, meaning the mechanic gave an inaccurate estimate. If giving an estimate, he should have said "from $200 to $900" or such. It would then be my fault if I were frustrated at the $900. (Or I could have asked him to reduce the uncertainty [reduce the range] but that might have cost me $75 for him to take the car apart to know exactly how he'd fix it.) This fits with your suggestion of incremental deliveries. However, there is still the possibility that incremental delivery ends up expensive. If I pay the mechanic $75 to take my car apart and he decides it will cost $900 total, I may decide to forgo the work in which case I'm out $75 of investigation cost. Hi Heiko–
Of course I would be frustrated if my mechanic initially told me $200 and later charged me $800. But let’s look at a couple of key assumptions. A key premise for me is that estimates need to *always* be accurate, meaning the mechanic gave an inaccurate estimate. If giving an estimate, he should have said “from $200 to $900″ or such. It would then be my fault if I were frustrated at the $900. (Or I could have asked him to reduce the uncertainty [reduce the range] but that might have cost me $75 for him to take the car apart to know exactly how he’d fix it.) This fits with your suggestion of incremental deliveries. However, there is still the possibility that incremental delivery ends up expensive. If I pay the mechanic $75 to take my car apart and he decides it will cost $900 total, I may decide to forgo the work in which case I’m out $75 of investigation cost.

]]> By: Heiko Stapf http://blog.mountaingoatsoftware.com/separate-estimating-from-committing/comment-page-1#comment-65733 Heiko Stapf Thu, 11 Feb 2010 12:18:29 +0000 http://blog.mountaingoatsoftware.com/?p=544#comment-65733 Hi, actually I wanted to disturb the peacefulness here a bit, but then my example "broke down" while writing ;) Let say you car is broken and you go to a mechanic and he tells you it will be finished tomorrow and it will cost you 200$. Three days later you get your car back and you'll have to pay 800$ and the mechanic tells you: "oh sorry, that was just an estimation". I actually wanted to point out, that this is a very unpleasant situation, but then I realised that it is also a very common one too. But still unpleasant. While I fully support the differentiation between estimation and commitment, we still have to find ways for both "parties" to be happy with. For me this allways leads to small, but committed(!) deliveries in order to build trust and that you constantly have to monitor and discuss deviations from the original estimation with your client. At the time of the estimation not only the costs are estimated but also the result. In a trustful relationship there is always a lot of you can talk about. The goal is to make the estimation become real - "estimation is not commitment" should not be an excuse for "neverending" projects or high costs, but a call to work together to meet the expectations of both parties at the end. Heiko Hi,

actually I wanted to disturb the peacefulness here a bit, but then my example “broke down” while writing ;)

Let say you car is broken and you go to a mechanic and he tells you it will be finished tomorrow and it will cost you 200$. Three days later you get your car back and you’ll have to pay 800$ and the mechanic tells you: “oh sorry, that was just an estimation”.

I actually wanted to point out, that this is a very unpleasant situation, but then I realised that it is also a very common one too. But still unpleasant.

While I fully support the differentiation between estimation and commitment, we still have to find ways for both “parties” to be happy with. For me this allways leads to small, but committed(!) deliveries in order to build trust and that you constantly have to monitor and discuss deviations from the original estimation with your client.

At the time of the estimation not only the costs are estimated but also the result. In a trustful relationship there is always a lot of you can talk about.

The goal is to make the estimation become real – “estimation is not commitment” should not be an excuse for “neverending” projects or high costs, but a call to work together to meet the expectations of both parties at the end.

Heiko

]]> By: Scrum 4 You — Don’t Mix Up Estimations and Commitments http://blog.mountaingoatsoftware.com/separate-estimating-from-committing/comment-page-1#comment-65719 Scrum 4 You — Don’t Mix Up Estimations and Commitments Thu, 11 Feb 2010 08:31:33 +0000 http://blog.mountaingoatsoftware.com/?p=544#comment-65719 [...] [1] http://blog.mountaingoatsoftware.com/separate-estimating-from-committing [...] [...] [1] http://blog.mountaingoatsoftware.com/separate-estimating-from-committing [...]

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/separate-estimating-from-committing/comment-page-1#comment-65702 Mike Cohn Wed, 10 Feb 2010 23:09:05 +0000 http://blog.mountaingoatsoftware.com/?p=544#comment-65702 Hi Deusdit-- I haven't said we should always communicate the estimate. :( Before determining the commitment we need to think about the audience. If you decide "4-6 sprints" is your estimate and need to convey that to someone who will hear "4" when told "4-6" then think about whether you really want to say "4-6." The loser in this situation is the recipient of the commitment who, by that unreasonable behavior, loses the opportunity to learn the full estimate. Hi Deusdit–
I haven’t said we should always communicate the estimate. :( Before determining the commitment we need to think about the audience. If you decide “4-6 sprints” is your estimate and need to convey that to someone who will hear “4″ when told “4-6″ then think about whether you really want to say “4-6.” The loser in this situation is the recipient of the commitment who, by that unreasonable behavior, loses the opportunity to learn the full estimate.

]]> By: Deusdit http://blog.mountaingoatsoftware.com/separate-estimating-from-committing/comment-page-1#comment-65701 Deusdit Wed, 10 Feb 2010 22:58:56 +0000 http://blog.mountaingoatsoftware.com/?p=544#comment-65701 This is true, but what can you do when the managers don't understand this distinction, when they think the estimation has to be "realistic" (it means a commitment)? I saw cases when the managers think that if the estimation is not a commitment, then the developers have an "open door" to do not accomplish with the tasks created in the project in the time estimated. What do you think about this Mike? This is true, but what can you do when the managers don’t understand this distinction, when they think the estimation has to be “realistic” (it means a commitment)? I saw cases when the managers think that if the estimation is not a commitment, then the developers have an “open door” to do not accomplish with the tasks created in the project in the time estimated.

What do you think about this Mike?

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/separate-estimating-from-committing/comment-page-1#comment-65686 Mike Cohn Wed, 10 Feb 2010 17:05:08 +0000 http://blog.mountaingoatsoftware.com/?p=544#comment-65686 Hi Tim-- Great point. I used to make that point in my classes as an advantage to story points. I think I'd forgotten it because I don't think I've mentioned it the last couple of times. Thanks for the reminder of another benefit to story points. Hi Tim–
Great point. I used to make that point in my classes as an advantage to story points. I think I’d forgotten it because I don’t think I’ve mentioned it the last couple of times. Thanks for the reminder of another benefit to story points.

]]>