Comments on: Sure Shot Method to Improve Quality of Your Estimates http://blog.brodzinski.com/2009/05/sure-shot-method-to-improve-quality-of.html Dealing with software projects in real life Fri, 10 Feb 2012 19:07:34 +0000 hourly 1 http://wordpress.org/?v=3.3 By: Pawel Brodzinski http://blog.brodzinski.com/2009/05/sure-shot-method-to-improve-quality-of.html#comment-2299 Pawel Brodzinski Fri, 15 May 2009 07:01:00 +0000 http://blog.brodzinski.com/2009/05/sure-shot-method-to-improve-quality-of-your-estimates.html#comment-2299 Good point. Actually if we do simple analysis how much time you spend on activities non-related wit task you may and with something like 50% if you're out of luck.<br /><br />On the other hand it can differ much. At the moment I work with small team where impact of the issue is minimal. Meetings, except of these tightly connected with tasks (e.g. on design or architecture), are non-existent. Interruption rate is incredibly low. There's no task switching. It's hard to measure precisely but I'd say the team is very productive.<br /><br />And I have to admit accuracy of estimates is pretty high too. Good point. Actually if we do simple analysis how much time you spend on activities non-related wit task you may and with something like 50% if you’re out of luck.

On the other hand it can differ much. At the moment I work with small team where impact of the issue is minimal. Meetings, except of these tightly connected with tasks (e.g. on design or architecture), are non-existent. Interruption rate is incredibly low. There’s no task switching. It’s hard to measure precisely but I’d say the team is very productive.

And I have to admit accuracy of estimates is pretty high too.

]]> By: splashup http://blog.brodzinski.com/2009/05/sure-shot-method-to-improve-quality-of.html#comment-2298 splashup Thu, 14 May 2009 23:21:00 +0000 http://blog.brodzinski.com/2009/05/sure-shot-method-to-improve-quality-of-your-estimates.html#comment-2298 I agree with you on splitting bigs tasks to smaller ones enhances our estimates. <br />But I believe that bigger contributor to the problem is that we don't plan for the symantics around the task: meetings, discussions, preparations, checking, and all that is NOT the buffer we should give for "possible" obstacles like TFS server going down, or Bug in 3rd party component, these are the real delays as I see it.<br />The task is not only the key stroking part. I agree with you on splitting bigs tasks to smaller ones enhances our estimates.
But I believe that bigger contributor to the problem is that we don’t plan for the symantics around the task: meetings, discussions, preparations, checking, and all that is NOT the buffer we should give for “possible” obstacles like TFS server going down, or Bug in 3rd party component, these are the real delays as I see it.
The task is not only the key stroking part.

]]> By: Tomek Dabrowski http://blog.brodzinski.com/2009/05/sure-shot-method-to-improve-quality-of.html#comment-2297 Tomek Dabrowski Tue, 12 May 2009 13:46:00 +0000 http://blog.brodzinski.com/2009/05/sure-shot-method-to-improve-quality-of-your-estimates.html#comment-2297 Pawel,<br /><br />The average velocity per person is 6-7 Story Points. <br /><br />Question 1. We are trying to descope story by making some additional assumptions. Or we commit that this story will be implemented however it will not cover all functionality mentioned at beginning.<br /><br />Question 2. Yes, we had a situation where the whole functionality had been splitted into 4 stories, and we hadn't chance to present the progress of work to customer as only having all stories implemented makes sense from business perspective. What we agreed is that set of integration/functional tests would have been produced to each story (yeah, I know this is not the perfect way). Pawel,

The average velocity per person is 6-7 Story Points.

Question 1. We are trying to descope story by making some additional assumptions. Or we commit that this story will be implemented however it will not cover all functionality mentioned at beginning.

Question 2. Yes, we had a situation where the whole functionality had been splitted into 4 stories, and we hadn’t chance to present the progress of work to customer as only having all stories implemented makes sense from business perspective. What we agreed is that set of integration/functional tests would have been produced to each story (yeah, I know this is not the perfect way).

]]> By: Pawel Brodzinski http://blog.brodzinski.com/2009/05/sure-shot-method-to-improve-quality-of.html#comment-2296 Pawel Brodzinski Tue, 12 May 2009 11:44:00 +0000 http://blog.brodzinski.com/2009/05/sure-shot-method-to-improve-quality-of-your-estimates.html#comment-2296 Tomek,<br /><br />One question just out of curiosity: what's your team velocity?<br /><br />And the another one connected with the problem you've brought: what do you do with tasks/stories which don't suit your sprint? If there's something too big to fit in one piece and there isn't any method to split it to separate wholes.<br /><br />Do you roll out some code which isn't completed from functional point of view? Tomek,

One question just out of curiosity: what’s your team velocity?

And the another one connected with the problem you’ve brought: what do you do with tasks/stories which don’t suit your sprint? If there’s something too big to fit in one piece and there isn’t any method to split it to separate wholes.

Do you roll out some code which isn’t completed from functional point of view?

]]> By: Tomek Dabrowski http://blog.brodzinski.com/2009/05/sure-shot-method-to-improve-quality-of.html#comment-2295 Tomek Dabrowski Tue, 12 May 2009 11:12:00 +0000 http://blog.brodzinski.com/2009/05/sure-shot-method-to-improve-quality-of-your-estimates.html#comment-2295 Idea of splitting stories works in our team quite well. <br /><br />One thought about estimation... Initial estimate for story is done using Story Points. The idea behind is that the maximum size for story that fits into iteration is 8 SPs so if story has more than that it needs to be divided into substories in order to be taken into account during Iteration Planning. The one tricky thing here is that sometimes it's very hard to split story into smaller pieces, as there are some dependencies and implementing only one piece does not bring any ROI for customer. Anyway, that's true that smaller work is easier to estimate. Idea of splitting stories works in our team quite well.

One thought about estimation… Initial estimate for story is done using Story Points. The idea behind is that the maximum size for story that fits into iteration is 8 SPs so if story has more than that it needs to be divided into substories in order to be taken into account during Iteration Planning. The one tricky thing here is that sometimes it’s very hard to split story into smaller pieces, as there are some dependencies and implementing only one piece does not bring any ROI for customer. Anyway, that’s true that smaller work is easier to estimate.

]]> By: Pawel Brodzinski http://blog.brodzinski.com/2009/05/sure-shot-method-to-improve-quality-of.html#comment-2294 Pawel Brodzinski Sun, 10 May 2009 07:24:00 +0000 http://blog.brodzinski.com/2009/05/sure-shot-method-to-improve-quality-of-your-estimates.html#comment-2294 Vukoje,<br /><br />Interesting, but it looks like overkill to me. Naming specific problems you're going to face is more like clairvoyance than real estimation.<br /><br />However the example is insightful in terms of raising awareness what we do wrong when estimating. Vukoje,

Interesting, but it looks like overkill to me. Naming specific problems you’re going to face is more like clairvoyance than real estimation.

However the example is insightful in terms of raising awareness what we do wrong when estimating.

]]> By: Vukoje http://blog.brodzinski.com/2009/05/sure-shot-method-to-improve-quality-of.html#comment-2293 Vukoje Sun, 10 May 2009 00:47:00 +0000 http://blog.brodzinski.com/2009/05/sure-shot-method-to-improve-quality-of-your-estimates.html#comment-2293 This peace of advice is something I was looking for few years before a friend simply told me that I can not estimate nothing and that key to success is to keep estimations small.<br /><br />He demonstrate his point with this excellent example of <br /><a HREF="http://www.tomsarazac.com/tom/opinions/fiveminute.html" REL="nofollow">5 minute task estimation.</a> This peace of advice is something I was looking for few years before a friend simply told me that I can not estimate nothing and that key to success is to keep estimations small.

He demonstrate his point with this excellent example of
5 minute task estimation.

]]> By: Pawel Brodzinski http://blog.brodzinski.com/2009/05/sure-shot-method-to-improve-quality-of.html#comment-2292 Pawel Brodzinski Fri, 08 May 2009 18:33:00 +0000 http://blog.brodzinski.com/2009/05/sure-shot-method-to-improve-quality-of-your-estimates.html#comment-2292 I think there's no technique which would help to estimate better tasks which aren't there. The problem wasn't within estimation but within break-down excercise.<br /><br />And I think if you had just several 60-day long tasks you would give you more crappy schedule anyway. I think there’s no technique which would help to estimate better tasks which aren’t there. The problem wasn’t within estimation but within break-down excercise.

And I think if you had just several 60-day long tasks you would give you more crappy schedule anyway.

]]> By: Anonymous http://blog.brodzinski.com/2009/05/sure-shot-method-to-improve-quality-of.html#comment-2291 Anonymous Fri, 08 May 2009 17:19:00 +0000 http://blog.brodzinski.com/2009/05/sure-shot-method-to-improve-quality-of-your-estimates.html#comment-2291 Our last BUFD project had no task over 12 hours ('cept project level tasks, e.g. "Project Management", "Issue Investigation"). Took us 5 man-months to come up with a schedule.<br /><br />The big problem was that all the tasks we completely <i>missed</i>. Our last BUFD project had no task over 12 hours (‘cept project level tasks, e.g. “Project Management”, “Issue Investigation”). Took us 5 man-months to come up with a schedule.

The big problem was that all the tasks we completely missed.

]]> By: Pawel Brodzinski http://blog.brodzinski.com/2009/05/sure-shot-method-to-improve-quality-of.html#comment-2290 Pawel Brodzinski Fri, 08 May 2009 17:06:00 +0000 http://blog.brodzinski.com/2009/05/sure-shot-method-to-improve-quality-of-your-estimates.html#comment-2290 The cool thing is the splitting tasks to smaller ones doesn't require any specific skill whatsoever. You just go a level, or a couple of levels, deeper with anlysis you anyway.<br /><br />One particular trick can be used to verify it's worth - do rough estimates with couple-of-weeks-long task granularity and then come with estimates broken down to small chunks. I bet the latter will be way more precise. The cool thing is the splitting tasks to smaller ones doesn’t require any specific skill whatsoever. You just go a level, or a couple of levels, deeper with anlysis you anyway.

One particular trick can be used to verify it’s worth – do rough estimates with couple-of-weeks-long task granularity and then come with estimates broken down to small chunks. I bet the latter will be way more precise.

]]>