我们所做的事情。

一些功能涉及新技术。我们无法准确估计它们。 点。

我们制定一个数字。基于几个因素。它的实现感觉有多难？我们是否可以通过某种“部分”或“刚好足够”的实现来完成？

• 如果它很难，那么就很难。它会很昂贵。

• 如果有很多部分，其中有好东西的核并加上一些奖励内容，我们就有可能只发布核部分，把其他东西留到以后处理。只有极少数的东西是“全有或者全无”的，无法进行部分发布。在这种情况下，我们必须为“全有”提供足够的时间，这会变得很昂贵。

我们的标准方法是获得能够工作的东西，并在由于意外复杂性而耗尽时间时可能延迟事情到以后的冲刺。

您所称的“调查”，我们称为技术突发冲刺。对于新的事物，我们会估算一个数字来取悦那些觉得必须过度策划事情的经理。然后我们会进行技术突发冲刺。一旦进行突发冲刺，我们就可以根据我们所知道的重新修订估算。

实际上，这个功能的实施花了27个小时 - 您忘记了第一轮7个小时的调查，因此实际上实施时间比预估时间长了近一倍。

你可以有两种选择方式：

1. 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
2. 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.

第一选择意味着您的冲刺和项目估计有些是主观的。第二个选择为您的冲刺提供了更多的可预测性。

在您的例子中，初始调查可能安排在Sprint 1，但是如果不知道任务需要多长时间，产品负责人就无法决定如何安排。如果您估计需要200个小时，产品负责人可能会决定根本不使用该功能，或者将其延迟到产品的第二版中。 估计完成后，产品负责人为Sprint 2安排了任务1、任务2和任务3的调查。在估计任务3之后，任务4和任务5可以在Sprint 3或以后安排。

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.

类似复杂度的功能需要相似的实现时间和努力。