Yes, your observations are exatly the sort of problems EBS is designed to solve.
Yes, it's important to break bigger tasks down. Shoot for 1-2 day tasks, more or less.
If you have things estimated at under 2 hrs, see if it makes sense to group them. (It might not -- that's ok!)
If you have tasks that are estimated at 3+ days, see if there might be a way to break them up into pieces. There should be. If the estimator says there is not, make them defend that assertion. If it turns out that the task really just takes 3 days, fine, but the more of these you have, the more you should be looking hard in the mirror and seeing if folks aren't gaming the system.
Count 4 & 5 day estimates as 2x and 4x as bad as 3 day ones. Anyone who says something is going to take longer than 5 days and it can't be broken down, tell them you want them to spend 4 hrs thinking about the problem, and how it can be broken down. Remember, that's a task, btw.
As you and your team practice this, you will get better at estimating.
...You will also start to recognize patterns of failure, and solutions will present themselves.
The point of Evidence based scheduling is to use Evidence as the basis for your schedule, not a collection of wild-assed guesses. It's A Good Thing...!
I think it is a good idea. When people break tasks down - they figure out the specifics of the task, You may get small deviations here and there, this way or the other, they may compensate or not...but you get a feeling of what is happening. If you have a huge task of 30 hours - can take all 100. This is the worst that could happen. Manage the risk - split down. You already figured out these small deviation - you know what to do with them.
So make sure developers also know what they do and say :)
"So, is it really a good idea to let the programmers break down the 30 hours task down to 4 or 2 hours steps during estimations? Won't this raise the standard deviation? (Ok, let them break it down - but perhaps after the estimations?!)"
I certainly don't get this question at all.
What it sounds like you're saying (you may not be saying this, but it sure sounds like it)
The programmers can't estimate at all -- the numbers are always rounded to "magic" values and off by 2x.
I can't trust them to both define the work and estimate the time it takes to do the work.
Only I know the correct estimate for the time required to do the task. It's not a round 1/2 day multiple. It's an exact number of minutes.
Here's my follow-up questions:
What are you saying? What can't you do? What problem are you having? Why do you think the programmers estimate badly? Why can't they be trusted to estimate?
From your statements, nothing is broken. You're able to plan and execute to that plan. I'd say you were totally successful and doing a great job at it.
Ok, I have the answer. Yes it is right AND the observations I made (see question) are absolutely understandable. To be sure I made a small Excel simulation to ensure myself of what I was guessing.
If you add multiple small task with a high standard deviation to bigger tasks, they will have a lower deviation, because the small task partially compensate the uncertainty.
So the answer is: Yes, it will work, if you break down your tasks, so that they are about the same length. It's because the simulation will do the compensation for bigger tasks automatically. I do not need to worry about a higher standard deviation in the smaller tasks.
But I am sure you must not mix up low estimated tasks with high estimated tasks - because they simply do not have the same variance.
Hence, it's always better to break them down. :)
The Excel simulation I made:
create 50 rows with these columns:
first - a fixed value 2 (the very homogeneous estimation)
20 columns with some random function (e.g. "=rand()*rand()*20")
make sums fore each column
add "=VARIANCE(..)" for each random column
and add a variance calculation for the sums
The variance for each column in my simulation was about 2-3 and the variance of the sums below 1.
发布评论
评论（4）
我认为这是一个好主意。 当人们分解任务时——他们会弄清楚任务的具体细节，你可能会在这里或那里出现一些小偏差，这样或那样，他们可能会补偿或不补偿……但你会感觉到正在发生什么。
如果你有一个 30 小时的艰巨任务 - 可以花掉全部 100 个小时。这是可能发生的最糟糕的情况。
管理风险——分解。 你已经弄清楚了这些小偏差——你知道如何处理它们。
因此，请确保开发人员也知道他们做什么和说什么:)
I think it is a good idea. When people break tasks down - they figure out the specifics of the task, You may get small deviations here and there, this way or the other, they may compensate or not...but you get a feeling of what is happening.
If you have a huge task of 30 hours - can take all 100. This is the worst that could happen.
Manage the risk - split down. You already figured out these small deviation - you know what to do with them.
So make sure developers also know what they do and say :)
“那么，让程序员在估算期间将 30 小时的任务分解为 4 或 2 小时的步骤，真的是个好主意吗？这不会提高标准差吗？（好吧，让他们分解 - 但也许之后估计？！）”
我当然根本不明白这个问题。
你听起来像是在说什么（你可能不是这么说的，但听起来确实是这样）
程序员根本无法估计——数字总是四舍五入为“
我不能相信他们既定义工作又估计完成工作所需的时间。
只有我知道完成任务所需时间的正确估计。 这不是 1/2 天的倍数。 这是精确的分钟数。
这是我的后续问题：
你在说什么？ 你不能做什么？ 你有什么问题吗？ 为什么你认为程序员估算得不好？ 为什么不能相信他们的估计？
从你的陈述来看，没有任何问题。 您能够计划并执行该计划。 我想说你非常成功并且做得很好。
"So, is it really a good idea to let the programmers break down the 30 hours task down to 4 or 2 hours steps during estimations? Won't this raise the standard deviation? (Ok, let them break it down - but perhaps after the estimations?!)"
I certainly don't get this question at all.
What it sounds like you're saying (you may not be saying this, but it sure sounds like it)
The programmers can't estimate at all -- the numbers are always rounded to "magic" values and off by 2x.
I can't trust them to both define the work and estimate the time it takes to do the work.
Only I know the correct estimate for the time required to do the task. It's not a round 1/2 day multiple. It's an exact number of minutes.
Here's my follow-up questions:
What are you saying? What can't you do? What problem are you having? Why do you think the programmers estimate badly? Why can't they be trusted to estimate?
From your statements, nothing is broken. You're able to plan and execute to that plan. I'd say you were totally successful and doing a great job at it.
好的，我有答案了。 是的，这是正确的，而且我所做的观察（参见问题）是绝对可以理解的。 为了确保我的猜测正确，我做了一个小型的 Excel 模拟。
如果将多个具有高标准差的小任务添加到更大的任务中，它们的偏差将会更低，因为小任务部分地补偿了不确定性。
所以答案是：是的，如果你分解你的任务，使它们的长度大致相同，它就会起作用。 这是因为模拟会自动对更大的任务进行补偿。 我不需要担心较小任务中较高的标准偏差。
但我确信您绝不能将低估计任务与高估计任务混淆 - 因为它们根本没有相同的方差。
因此，最好将它们分解。 :)
我所做的 Excel 模拟：
我的模拟中每列的方差约为 2-3，总和的方差低于 1。
Ok, I have the answer. Yes it is right AND the observations I made (see question) are absolutely understandable. To be sure I made a small Excel simulation to ensure myself of what I was guessing.
If you add multiple small task with a high standard deviation to bigger tasks, they will have a lower deviation, because the small task partially compensate the uncertainty.
So the answer is: Yes, it will work, if you break down your tasks, so that they are about the same length. It's because the simulation will do the compensation for bigger tasks automatically. I do not need to worry about a higher standard deviation in the smaller tasks.
But I am sure you must not mix up low estimated tasks with high estimated tasks - because they simply do not have the same variance.
Hence, it's always better to break them down. :)
The Excel simulation I made:
The variance for each column in my simulation was about 2-3 and the variance of the sums below 1.