Some features involve new technology. We can't accurately estimate them. Period.
We make up a number. Based on a couple of things. How hard does it "feel"? Can we get by with some kind of "partial" or "just-enough" implementation?
If it's hard, then it's hard. It will be expensive.
If there's a lot of parts, with a kernel of goodness and some bonus stuff layered on, we have a possibility of putting just the kernel into a release, and setting other stuff aside for later. A very few things are "all or nothing" where a partial release isn't possible. In that case, we have to provide enough time for "all", and that gets expensive.
Our standard approach is to get stuff that works, and possibly defer things to a later sprint if we ran of out time because of unexpected complexities.
What you're calling "investigation", we call technical spike sprints. For stuff that's new, we make up estimate number to placate managers who feel it necessary to overplan things. Then we spike the technology. Once it's spiked, we can revise the estimates based on what we now know.
Actually, the implementation of the feature took 27 hours - you forgot the first investigation of 7 hours, so in reality the actual implementation took almost twice as long as the estimate.
There are two ways you can go on this:
Just make the estimate as best you can and potentially experience a blowout in your sprint and a declined project velocity (you should only do this if the feature is both urgent and critical); or
Schedule the investigation for this sprint and leave the implementation for another sprint - without an idea of how long the task will take, the Product Owner does not have enough information to make a decision about in which sprint to schedule it or even whether to do it at all. Only tasks that have been estimated should be included in your sprint.
The first choice means your sprint and project estimates are somewhat arbitrary. The second choice gives much more predictability to your sprints.
In your example, the initial investigation may be scheduled for Sprint 1 but without knowledge of how long the task will take the Product Owner can't decide how to schedule it. If you came back with an estimate of 200 hours the Product Owner may decide not to do that feature at all, or to delay it until Release 2 of the product. The estimate comes in and the Product Owner schedules Task 1, Task 2 and the investigation of Task 3 for Sprint 2. After estimating Task 3, Tasks 4 and 5 can be scheduled in Sprint 3 or later.
Estimating feature usually is complex task. After some time your estimation will become better. But good approach can be that you estimate features with the story points. Story point is abstract value (meaning agreed among the team) that express complexity of the problem. You should assign the same complexity (same number of story points) to the features of the similar complexity. Then later on it is enough to estimate only smaller set of features (or looking at the historical data) and you should be able to estimate how much time you need.
Features with the similar complexity need similar time effort for implementation.
发布评论
评论（3）
我们所做的。
一些功能涉及新技术。 我们无法准确估计它们。 时期。
我们凑个数。 基于几件事。 “感觉”有多难？ 我们可以通过某种“部分”或“刚好够用”的实施吗？
如果很难，那就很难了。 它会很昂贵。
如果有很多部分，并且有一个好的内核和一些额外的东西，我们有可能只将内核放入一个版本中，并将其他东西放在一边供以后使用。 极少数事情是“全有或全无”，其中部分发布是不可能的。 在这种情况下，我们必须为“所有”提供足够的时间，这会变得昂贵。
我们的标准方法是获得可行的东西，如果由于意外的复杂性而耗尽了时间，则可能会将事情推迟到以后的冲刺。
你所说的“调查”，我们称之为技术冲刺。 对于新事物，我们会编造预估数字，以安抚那些认为有必要过度计划事物的经理。 然后我们对技术进行峰值。 一旦达到峰值，我们就可以根据我们现在所知道的情况修改估计值。
What we do.
Some features involve new technology. We can't accurately estimate them. Period.
We make up a number. Based on a couple of things. How hard does it "feel"? Can we get by with some kind of "partial" or "just-enough" implementation?
If it's hard, then it's hard. It will be expensive.
If there's a lot of parts, with a kernel of goodness and some bonus stuff layered on, we have a possibility of putting just the kernel into a release, and setting other stuff aside for later. A very few things are "all or nothing" where a partial release isn't possible. In that case, we have to provide enough time for "all", and that gets expensive.
Our standard approach is to get stuff that works, and possibly defer things to a later sprint if we ran of out time because of unexpected complexities.
What you're calling "investigation", we call technical spike sprints. For stuff that's new, we make up estimate number to placate managers who feel it necessary to overplan things. Then we spike the technology. Once it's spiked, we can revise the estimates based on what we now know.
实际上，该功能的实施花了 27 个小时——你忘了第一次调查花了 7 个小时，所以实际上实际实施花费的时间几乎是估计的两倍。
有两种方法可以继续此操作：
第一个选择意味着您的冲刺和项目估计有些随意。 第二种选择为您的冲刺提供了更多的可预测性。
在您的示例中，初步调查可能安排在 Sprint 1，但在不知道任务需要多长时间的情况下，产品负责人无法决定如何安排它。 如果您回来时估计需要 200 小时，产品负责人可能会决定根本不执行该功能，或者将其推迟到产品的第 2 版。 估算完成后，产品负责人为 Sprint 2 安排任务 1、任务 2 和任务 3 的调查。估算任务 3 后，可以在 Sprint 3 或更高版本中安排任务 4 和 5。
Actually, the implementation of the feature took 27 hours - you forgot the first investigation of 7 hours, so in reality the actual implementation took almost twice as long as the estimate.
There are two ways you can go on this:
The first choice means your sprint and project estimates are somewhat arbitrary. The second choice gives much more predictability to your sprints.
In your example, the initial investigation may be scheduled for Sprint 1 but without knowledge of how long the task will take the Product Owner can't decide how to schedule it. If you came back with an estimate of 200 hours the Product Owner may decide not to do that feature at all, or to delay it until Release 2 of the product. The estimate comes in and the Product Owner schedules Task 1, Task 2 and the investigation of Task 3 for Sprint 2. After estimating Task 3, Tasks 4 and 5 can be scheduled in Sprint 3 or later.
估计特征通常是一项复杂的任务。 一段时间后，你的估计会变得更好。 但好的方法是用故事点来估计特征。 故事点是表达问题复杂性的抽象值（意味着团队之间达成一致）。
您应该为相似复杂度的特征分配相同的复杂度（相同数量的故事点）。 然后，稍后只估计较小的特征集（或查看历史数据）就足够了，您应该能够估计需要多少时间。
具有相似复杂性的功能需要相似的时间来实现。
Estimating feature usually is complex task. After some time your estimation will become better. But good approach can be that you estimate features with the story points. Story point is abstract value (meaning agreed among the team) that express complexity of the problem.
You should assign the same complexity (same number of story points) to the features of the similar complexity. Then later on it is enough to estimate only smaller set of features (or looking at the historical data) and you should be able to estimate how much time you need.
Features with the similar complexity need similar time effort for implementation.