A lot of good answers here, so I'll play devil's advocate and approach it from a different side.
There's a possible problem with breaking down things into very small estimates (# of hours) when doing things such as release planning. David Anderson discusses it in his (excellent) book Agile Management for Software Engineering.
Basically, the idea is that with a task that is very small, a developer will pad his estimate by a fair bit (say, turning a half hour into an hour, or doubling it) because of a certain amount of ego that would be bruised if the developer failed to complete such a small task in the estimated time. These local buffers add up quite a bit and result in a global buffer that's far bigger than it needs to be.
This is less of a problem if you stick with .5 days as a min - it's basically assumed that there's some buffer in there, so you won't need to pad it any more.
I feel there is a bit of mix of information and overlapping in this thread... allow me to make my point :-)
1) The Fibonacci sequence, that is very much use through the Planning Poker technique from Mike Cohn, is about estimating "Complexity" of User Stories, which are - as Cam said - normally written on cards, and entail more than one task, at least all of those which will be needed to make a Story shippable (Ken Schwaber, Alistar Cockburn, Mike Cohn...)
2) The tasks that are included to complete a Story, are normally estimated in Ideal Hours or Pomodori (Francesco Cirillo, "The Pomodoro technique"). If you estimate in Ideal Hours normally the rule of thumb is to keep them between 1/2 day (3 ideal hours) and 2 days (12 ideal hours) of work. The reason for this is that doing so the team will have more qualitative status information by having at least every two days a team member reporting a Task as done, which is much more "valuable" than a 60% done. If you use Pomodori they are implicitly "timeboxed" to 25 min. each
The reason to keep tasks small comes basically from the "Empirical Process Control Theory" for which through transparency and regular inspection & adaption, you can better check the progress of your work, by quantifying it. The goal of having smaller tasks is to be able to clearly describe and envision in details what will be actually done, without adding too much of "guessing" given to the natural uncertainty deriving from having to predict "the future". Moreover defining an outcome and a shorter timebox allow people to keep the focus with enough "sense of urgency" to make it a challenging and motivating experience.
I would also catch up the point of the "motivation" and "ego" - from Chris - by adding that a good way to have people committed and motivated is to define the expected outcome of a task, so to be able to measure the results upon completion, and celebrate the success. This idea is encapsulated in the Pomodoro Technique, but can be achieved also using ideal hours for estimation. Another interesting part of the Pomodoro Technique is that "breaks" are considered "First Class Citizens" and planned regularly, which is very important especially in creative and brain intensive activities :-)
It tends to be a good rule of thumb (agile or not) that your tasks should be broken down into at most 1 - 2 day increments.
The idea is that if you have larger chunks than that then you haven't broken the task down enough and you will more likely miss the estimate and miss it by larger amounts of time than had you broke it down. Often when you break it down you discover your initial estimate was off and since you have broken the task down into more concrete tasks your estimate is now more accurate, more trackable and meaningful.
For tasks that are coming up on your to do list soon you should pay attention to this but for long range planning where you haven't necessarily thought out the feature in detail I think larger estimates / tasks not broken out for the feature is OK.
Here's a link to Joel Spolsky talking about this. Take a look at item #5 about half way down the page.
In my experience, any estimate that's longer than 2 days is probably hiding serious work that should be broken down further. Such estimates have a very high probability of going over. Try to break everything down into smaller chunks so that no individual chunk costs more than 1-2 days.
There are advantages to keeping the estimates short. It forces you to break up large tasks into small, discrete tasks that can be measured and discussed quickly, which helps promote the entire Agile development process.
That being said, I almost never keep a "rule" as a hard and fast rule with things like this. I'd say this is a good guideline, however.
My team consists of junior programmers (university students) and we've found that it's generally easier if we break all the large tasks down into a bunch of smaller ones. It involves more forward-thinking but in the end we are more productive and can it's easier to evaluate our progress. It also brings a sense of achievement when you have something completed at the end of the day.
I would agree with that guideline. Anytime I have ever taken on a 5 day task, it has degenerated to a three week nightmare. Large estimates indicate you didn't learn enough about the problem up front to know what is involved, because if you had, you could have found ways to break it up better.
I don't agree. If a team's iterations are two week long, the 10 days mean that 1 day would be spent for iteration close (show & tell), iteration planning and tasking or planning poker.
When playing planning poker, a team either geometric or Fibonacci progressions for estimates. For example, cards would contain values such as 1, 2, 4, 8, 16 or 1, 2, 3, 5, 8, 13. Each number reflects the number of days of development for a pair of programmers.
For each card, once discussion has occurred, each member simultaneously plays the card that reflects their estimate. If the majority of the team converges on the same estimate, the estimate is accepted. If there is much variation in the estimates, further discussion occurs (members explain the reason for their estimates) and another round of voting takes place. This occurs until consensus is reached.
If a number greater than 8 is picked, then the card is deemed to be too big and the card is refactored into at least 2 smaller cards. The reason being is that such a large estimate indicates the card is too big to be completed in a single iteration and any estimate is very likely to be inaccurate.
Using such a method brings commitment from the team members to delivery all they have committed to and for a new team the estimate become so accurate that carry over of cards soon become a low risk.
发布评论
评论（9）
您可以在agile42的博客上找到一篇关于敏捷估算和规划的非常好的文章：恰到好处，恰到好处
A very good post about agile estimation and planning you can find on the blog of agile42: Just enough, just in time
这里有很多很好的答案，所以我会唱反调，从不同的角度来处理这个问题。
在进行发布计划等工作时，将事情分解为非常小的估计（小时数）可能会出现问题。 David Anderson 在他的（优秀）著作软件工程的敏捷管理中对此进行了讨论。
基本上，这个想法是，对于一个非常小的任务，开发人员会将他的估计增加相当多的一点（例如，将半小时变成一个小时，或者加倍），因为一定程度的自我意识会受到伤害如果开发人员未能在预计时间内完成这么小的任务。这些本地缓冲区加起来相当多，导致全局缓冲区远远大于其需要的大小。
如果您坚持使用 0.5 天作为分钟，那么这就不是什么问题了 - 基本上假设那里有一些缓冲区，所以您不需要再填充它。
A lot of good answers here, so I'll play devil's advocate and approach it from a different side.
There's a possible problem with breaking down things into very small estimates (# of hours) when doing things such as release planning. David Anderson discusses it in his (excellent) book Agile Management for Software Engineering.
Basically, the idea is that with a task that is very small, a developer will pad his estimate by a fair bit (say, turning a half hour into an hour, or doubling it) because of a certain amount of ego that would be bruised if the developer failed to complete such a small task in the estimated time. These local buffers add up quite a bit and result in a global buffer that's far bigger than it needs to be.
This is less of a problem if you stick with .5 days as a min - it's basically assumed that there's some buffer in there, so you won't need to pad it any more.
我觉得这个线程中有一些信息的混合和重叠...请允许我阐述我的观点:-)
1) 斐波那契数列在 Mike Cohn 的规划扑克技术中非常有用，它是关于估计的用户故事的“复杂性”，正如 Cam 所说，通常写在卡片上，并且需要不止一项任务，至少是使故事可交付所需的所有任务（Ken Schwaber、Alistar Cockburn、Mike Cohn）。 ..)
2) 完成故事所包含的任务通常以理想时间或番茄时间来估计（Francesco Cirillo，“番茄工作法”）。如果您以理想工时进行估算，通常经验法则是将其保持在 1/2 天（3 个理想工时）和 2 天（12 个理想工时）之间。这样做的原因是，这样做团队将获得更多定性状态信息，至少每两天就有一名团队成员报告任务已完成，这比完成 60% 的任务更“有价值”。如果您使用番茄工作法，它们会隐式“时间盒”为 25 分钟。每个
保持小任务的原因基本上来自于“经验过程控制理论”，通过透明度和定期检查&适应，您可以通过量化来更好地检查工作进度。拥有较小任务的目标是能够清楚地描述和详细设想实际将要做什么，而不会因为必须预测“未来”而产生的自然不确定性而添加太多“猜测”。此外，定义结果和更短的时间范围可以让人们以足够的“紧迫感”保持注意力，使其成为一种具有挑战性和激励性的体验。
我还想了解克里斯的“动机”和“自我”的观点，补充说，让人们投入和激励的一个好方法是定义任务的预期结果，以便能够衡量结果完成后，庆祝成功。这个想法被封装在番茄工作法中，但也可以使用理想的时间进行估计来实现。番茄工作法的另一个有趣的部分是，“休息”被认为是“一等公民”并定期计划，这非常重要，尤其是在创造性和脑力密集型活动中:-)
你觉得怎么样？
最佳
安德烈亚特
I feel there is a bit of mix of information and overlapping in this thread... allow me to make my point :-)
1) The Fibonacci sequence, that is very much use through the Planning Poker technique from Mike Cohn, is about estimating "Complexity" of User Stories, which are - as Cam said - normally written on cards, and entail more than one task, at least all of those which will be needed to make a Story shippable (Ken Schwaber, Alistar Cockburn, Mike Cohn...)
2) The tasks that are included to complete a Story, are normally estimated in Ideal Hours or Pomodori (Francesco Cirillo, "The Pomodoro technique"). If you estimate in Ideal Hours normally the rule of thumb is to keep them between 1/2 day (3 ideal hours) and 2 days (12 ideal hours) of work. The reason for this is that doing so the team will have more qualitative status information by having at least every two days a team member reporting a Task as done, which is much more "valuable" than a 60% done. If you use Pomodori they are implicitly "timeboxed" to 25 min. each
The reason to keep tasks small comes basically from the "Empirical Process Control Theory" for which through transparency and regular inspection & adaption, you can better check the progress of your work, by quantifying it. The goal of having smaller tasks is to be able to clearly describe and envision in details what will be actually done, without adding too much of "guessing" given to the natural uncertainty deriving from having to predict "the future". Moreover defining an outcome and a shorter timebox allow people to keep the focus with enough "sense of urgency" to make it a challenging and motivating experience.
I would also catch up the point of the "motivation" and "ego" - from Chris - by adding that a good way to have people committed and motivated is to define the expected outcome of a task, so to be able to measure the results upon completion, and celebrate the success. This idea is encapsulated in the Pomodoro Technique, but can be achieved also using ideal hours for estimation. Another interesting part of the Pomodoro Technique is that "breaks" are considered "First Class Citizens" and planned regularly, which is very important especially in creative and brain intensive activities :-)
What do you think?
Best
ANdreaT
一个好的经验法则（敏捷与否）是，您的任务应该分解为最多 1 - 2 天的增量。
这个想法是，如果你有比这更大的块，那么你没有将任务分解得足够多，你将更有可能错过估计，并且错过它的时间比你分解它的时间更长。通常，当您分解任务时，您会发现最初的估计有所偏差，并且由于您已将任务分解为更具体的任务，因此您的估计现在更准确、更可跟踪且更有意义。
对于即将出现在待办事项列表中的任务，您应该注意这一点，但对于长期计划，您不一定详细考虑该功能，我认为对该功能未分解的较大估计/任务是可以的。
这是 Joel Spolsky 谈论此事的链接。看看页面中间的第 5 项。
http://www.joelonsoftware.com/articles/fog0000000245.html
It tends to be a good rule of thumb (agile or not) that your tasks should be broken down into at most 1 - 2 day increments.
The idea is that if you have larger chunks than that then you haven't broken the task down enough and you will more likely miss the estimate and miss it by larger amounts of time than had you broke it down. Often when you break it down you discover your initial estimate was off and since you have broken the task down into more concrete tasks your estimate is now more accurate, more trackable and meaningful.
For tasks that are coming up on your to do list soon you should pay attention to this but for long range planning where you haven't necessarily thought out the feature in detail I think larger estimates / tasks not broken out for the feature is OK.
Here's a link to Joel Spolsky talking about this. Take a look at item #5 about half way down the page.
http://www.joelonsoftware.com/articles/fog0000000245.html
根据我的经验，任何超过 2 天的估计都可能隐藏着应该进一步分解的严肃工作。这样的估计被推翻的可能性非常高。尝试将所有内容分解为更小的块，这样每个块的花费都不超过 1-2 天。
In my experience, any estimate that's longer than 2 days is probably hiding serious work that should be broken down further. Such estimates have a very high probability of going over. Try to break everything down into smaller chunks so that no individual chunk costs more than 1-2 days.
保持简短的估计是有好处的。它迫使你将大任务分解成小的、离散的任务，这些任务可以快速衡量和讨论，这有助于促进整个敏捷开发过程。
话虽这么说，我几乎从不把“规则”作为对待此类事情的硬性规定。不过，我想说这是一个很好的指导方针。
There are advantages to keeping the estimates short. It forces you to break up large tasks into small, discrete tasks that can be measured and discussed quickly, which helps promote the entire Agile development process.
That being said, I almost never keep a "rule" as a hard and fast rule with things like this. I'd say this is a good guideline, however.
我的团队由初级程序员（大学生）组成，我们发现，如果我们将所有大型任务分解为一堆较小的任务，通常会更容易。它涉及更多的前瞻性思维，但最终我们的生产力更高，并且更容易评估我们的进展。当你在一天结束时完成某件事时，它还会带来一种成就感。
My team consists of junior programmers (university students) and we've found that it's generally easier if we break all the large tasks down into a bunch of smaller ones. It involves more forward-thinking but in the end we are more productive and can it's easier to evaluate our progress. It also brings a sense of achievement when you have something completed at the end of the day.
我同意该指导方针。每当我执行为期 5 天的任务时，它都会变成一场三周的噩梦。大量的估计表明您没有事先对问题了解得足够多，无法了解所涉及的内容，因为如果您了解了，您可能会找到更好的方法来分解它。
I would agree with that guideline. Anytime I have ever taken on a 5 day task, it has degenerated to a three week nightmare. Large estimates indicate you didn't learn enough about the problem up front to know what is involved, because if you had, you could have found ways to break it up better.
我不同意。如果团队的迭代持续两周，那么这 10 天意味着 1 天将用于迭代结束（展示和讲述）、迭代计划和任务分配或计划扑克。
当玩计划扑克时，团队可以使用几何级数或斐波那契级数进行估计。例如，卡片将包含 1、2、4、8、16 或 1、2、3、5、8、13 等值。每个数字反映一对程序员的开发天数。
对于每张卡片，一旦进行讨论，每个成员都会同时打出反映他们估计的卡片。如果团队的大多数成员都同意相同的估计，则该估计被接受。如果估计值存在很大差异，则会进行进一步讨论（成员解释其估计值的原因）并进行另一轮投票。这种情况会持续到达成共识为止。
如果选择的数字大于 8，则该卡被视为太大，并且该卡将被重构为至少 2 张较小的卡。原因是，如此大的估计表明卡片太大而无法在单次迭代中完成，并且任何估计都很可能不准确。
使用这种方法可以使团队成员承诺兑现他们所承诺的一切，并且对于新团队来说，估算变得如此准确，以至于卡结转的风险很快就变得很低。
I don't agree. If a team's iterations are two week long, the 10 days mean that 1 day would be spent for iteration close (show & tell), iteration planning and tasking or planning poker.
When playing planning poker, a team either geometric or Fibonacci progressions for estimates. For example, cards would contain values such as 1, 2, 4, 8, 16 or 1, 2, 3, 5, 8, 13. Each number reflects the number of days of development for a pair of programmers.
For each card, once discussion has occurred, each member simultaneously plays the card that reflects their estimate. If the majority of the team converges on the same estimate, the estimate is accepted. If there is much variation in the estimates, further discussion occurs (members explain the reason for their estimates) and another round of voting takes place. This occurs until consensus is reached.
If a number greater than 8 is picked, then the card is deemed to be too big and the card is refactored into at least 2 smaller cards. The reason being is that such a large estimate indicates the card is too big to be completed in a single iteration and any estimate is very likely to be inaccurate.
Using such a method brings commitment from the team members to delivery all they have committed to and for a new team the estimate become so accurate that carry over of cards soon become a low risk.