I'm not sure what the term is in Scrum, but in User Story terminology you would do a "spike", which is basically a very short period of research into the topic so that your team will be able to estimate the task at the end of the spike.
Example:
Story:
Analyst wants to be able to review financial data in pie charts.
Your team doesn't use any charting tools, so you need to know how long it would take to build something like this. Or perhaps instead, you could invest in third party tooling and integrate a tooling set with your application.
You would do a spike to research these venues and come up with estimations on them, then decide which route to take.
Are the "tasks" things that someone in the world has done before, or are they just new to your team. I will assume the later. If this is the case then what you are finding is that you do not have the necessary experience on your team to solve the problem. Thus you will be developing that experience as you go. All this means is that the complexity of your stories is higher. In the first couple of sprints you may score some of the stories as 13 and then later on they become 8s because you then have the knowledge you need.
You don't need to know how to do the stories to estimate them. You just need to take on less of them due to your experience gap.
I like to reserve "Spikes" (yes that is the term used in scrum) for attempting to solve business domain problems that have no known solution. Not for the team to do training.
If you really need to do research to get a good estimate, you could do the research as a task in itself, or set it aside and have it done (by someone) before the sprint planning.
Generally, I think that if you can't get a good estimate, you should either go with a bad estimate (i.e. a wild guess) or you should time-box the task, so you set aside a fixed amount of time for it in a sprint. After that, you will either have a done solution, or you will have a better understaning of it so you can estimate it or break it down into subtasks for the next sprint (or a later sprint).
Do you really mean tasks or are you talking about Product Backlog Items (PBIs)? Actually, I find it hard to believe that a task is not estimable. If they really aren't, they are very likely too big (tasks shouldn't exceed 16h, which is already huge).
If you are talking about PBIs, the situation you are describing is quite surprising and should theoretically not happen. In the worst case, just assign them a high number of story points, this precisely means that there is a lot of uncertainty on them. But, because PBIs that are ready for a Sprint shouldn't exceed the half of your velocity (or you'll put too much risk on your sprint), the obvious way to solve this situation is to divide such items into smaller chunks which may include exploration. But the important part is to keep things timeboxed, even (or especially) R&D. Keep in mind that with Scrum, everything is timeboxed.
In other words, to reduce uncertainty, break things down into smaller things (be them items or tasks)!
如果任务看起来无法估计，我认为最好的方法是将这些任务分解为可以估计的更小的任务。这可能需要多次迭代，但您可能会在进行过程中想出一个伪设计。 Joel 在他的一篇文章中提到了这一点。
If the tasks seem un-estimable, I think the best approach would be to break down those tasks into smaller tasks that you can estimate. It might take several iterations, but you will probably come up with a pseudo design while you are at it. Joel mentions this in one of his articles.
Split the unestimatable task into a task to remove the uncertainty, and "the rest". Remove uncertainty with Proof-of-concept tests or spike solutions. Either schedules the spikes this sprint and the rest of the work next sprint, Or delay the start of the sprint for a week of spiking.
We often don't know enough to break a story down into tasks. We have a period of discovery before we know what the tasks will be. "Spikes" seem tricky to manage. For one, you may not be able to time box the discovery period. Second, I can't effectively plan a sprint without knowing how long a story will take.
Seems like another option is to do the spike in Sprint 1 and the tasks in Sprint 2. The downside is that it seems like the process forces an unnatural breakdown of the work. Why discover this week and then wait a while before starting the the work.
We use "contingents" or a specific backlog for such tasks. The Scrum Tool Agilo is supporting this way of working and calculates those issues too, e.g. in the Burndown. In this way you get a good control on the "un-plannable" items.
The idea behind Agile estimation is to come up with a number that is good enough, not a number that is exact. That is why using story points for backlog item estimation is a best practice; it emphasizes effort/complexity instead of duration.
You don't need to know how long each task necessary to implement a backlog item in a sprint will take. What you need to know is, given the work you've previously committed to in this sprint, can you commit to this backlog item? Because we know that we can't know exactly how much time each backlog item will take, we have to make an educated guess.
More important, what does it mean to fail in Scrum? Is not getting every sprint backlog item completed a failure? No... if you got four out of five items done and the fifth one is mostly done, you'll get credit for the four completed items (in terms of velocity for the sprint), and when you finish the remaining tasks for that fifth item in a future sprint you will get full credit for that item. But, would you have gotten any more done if you weren't using Scrum? The only failure in Scrum is failing to learn from your mistakes, to keep doing the same dysfunctional things repeatedly while expecting different results.
So, in your sprint planning meeting, don't spend a lot of time worrying about something you're not going to be able to know. Let the team think about the work, and then let them sign up for the amount of work they feel comfortable they can complete during the sprint. If they undercommit you can always drag something into the backlog, or end the sprint early. If they overcommit, then you finish the backlog items you can in priority order and discuss why the unfinished items couldn't be finished in the sprint retrospective, along with how to prevent having unfinished items in future sprints.
By the way, I know this was probably a poor choice of words on your part, but an effective Scrum Master doesn't run the sprint. The team runs the sprint, and the Scrum Master actively looks for impediments that lower their productivity and interfere with their ability to meet their commitments. Scrum Masters aren't managers, they're a combination of referee, coach, and scorekeeper. They are the Keeper of the Process, they help the team follow the process, they protect the team from outside agents that try to go around the process, and they track progress during the sprint via ensuring the sprint backlog is updated and the sprint burndown chart reflects reality, on a daily basis. In the situation you've described, where the team isn't sure how much work they should sign up for, the Scrum Master should let the team decide as a reflection of respect for team ownership of the commitment. Whatever the decision is, it won't be wrong.
Spikes should be time boxed. It puts on pressure on the team to limit the scope and have a better idea on the cost-benefits that the research will entail; ie it is useless to carry out 3 days of research for a task which would cost a few bucks.
This is also backed up by Latham's work on Goal Setting Theory where he specifically tackles this issue.
发布评论
评论（10）
我不确定 Scrum 中的术语是什么，但在用户故事术语中，您会进行“尖峰”，这基本上是对该主题进行非常短的研究，以便您的团队能够在尖峰的末端。
例子：
您的团队不使用任何图表工具，因此您需要知道构建这样的东西需要多长时间。或者，您可以投资第三方工具并将工具集与您的应用程序集成。
您需要对这些场所进行大量研究并对其进行估计，然后决定采取哪条路线。
I'm not sure what the term is in Scrum, but in User Story terminology you would do a "spike", which is basically a very short period of research into the topic so that your team will be able to estimate the task at the end of the spike.
Example:
Your team doesn't use any charting tools, so you need to know how long it would take to build something like this. Or perhaps instead, you could invest in third party tooling and integrate a tooling set with your application.
You would do a spike to research these venues and come up with estimations on them, then decide which route to take.
这些“任务”是世界上有人以前做过的事情，还是对您的团队来说是新的事情。我会假设后者。如果是这种情况，那么您会发现您的团队没有解决问题所需的经验。因此，您将在前进的过程中发展这种体验。所有这一切都意味着你的故事的复杂性更高。在前几个冲刺中，您可能会给某些故事打分 13 分，然后它们会变成 8 分，因为您已经掌握了所需的知识。
你不需要知道如何编写故事来估计它们。由于你的经验差距，你只需要减少他们的数量。
我喜欢保留“Spikes”（是的，这是 scrum 中使用的术语）来尝试解决没有已知解决方案的业务领域问题。不是为了球队做训练。
Are the "tasks" things that someone in the world has done before, or are they just new to your team. I will assume the later. If this is the case then what you are finding is that you do not have the necessary experience on your team to solve the problem. Thus you will be developing that experience as you go. All this means is that the complexity of your stories is higher. In the first couple of sprints you may score some of the stories as 13 and then later on they become 8s because you then have the knowledge you need.
You don't need to know how to do the stories to estimate them. You just need to take on less of them due to your experience gap.
I like to reserve "Spikes" (yes that is the term used in scrum) for attempting to solve business domain problems that have no known solution. Not for the team to do training.
如果您确实需要进行研究以获得良好的估计，您可以将研究本身作为一项任务来进行，或者将其放在一边并在冲刺计划之前由某人完成。
一般来说，我认为如果你不能得到一个好的估计，你应该要么做出一个错误的估计（即疯狂的猜测），要么你应该对任务进行时间限制，这样你就可以为它留出固定的时间冲刺。之后，您将获得一个完整的解决方案，或者您将对其有更好的理解，以便您可以对其进行估计或将其分解为下一个冲刺（或稍后的冲刺）的子任务。
If you really need to do research to get a good estimate, you could do the research as a task in itself, or set it aside and have it done (by someone) before the sprint planning.
Generally, I think that if you can't get a good estimate, you should either go with a bad estimate (i.e. a wild guess) or you should time-box the task, so you set aside a fixed amount of time for it in a sprint. After that, you will either have a done solution, or you will have a better understaning of it so you can estimate it or break it down into subtasks for the next sprint (or a later sprint).
您真正指的是任务还是您正在谈论的产品待办事项 (PBI)？事实上，我很难相信一项任务是不可估量的。如果确实不是，那么它们很可能太大（任务不应超过 16 小时，这已经很大了）。
如果您谈论的是 PBI，那么您所描述的情况是相当令人惊讶的，理论上应该不会发生。在最坏的情况下，只要给他们分配大量的故事点，这恰恰意味着他们有很多不确定性。但是，因为准备好 Sprint 的 PBI 不应超过速度的一半（否则你会给 Sprint 带来太大的风险），解决这种情况的明显方法是将这些项目分成更小的块，这可能会导致包括探索。但重要的是要保持时间限制，甚至（或特别是）研发。请记住，对于 Scrum，一切都是有时间限制的。
换句话说，为了减少不确定性，请将事物分解为更小的事物（无论是项目还是任务）！
Do you really mean tasks or are you talking about Product Backlog Items (PBIs)? Actually, I find it hard to believe that a task is not estimable. If they really aren't, they are very likely too big (tasks shouldn't exceed 16h, which is already huge).
If you are talking about PBIs, the situation you are describing is quite surprising and should theoretically not happen. In the worst case, just assign them a high number of story points, this precisely means that there is a lot of uncertainty on them. But, because PBIs that are ready for a Sprint shouldn't exceed the half of your velocity (or you'll put too much risk on your sprint), the obvious way to solve this situation is to divide such items into smaller chunks which may include exploration. But the important part is to keep things timeboxed, even (or especially) R&D. Keep in mind that with Scrum, everything is timeboxed.
In other words, to reduce uncertainty, break things down into smaller things (be them items or tasks)!
如果任务看起来无法估计，我认为最好的方法是将这些任务分解为可以估计的更小的任务。这可能需要多次迭代，但您可能会在进行过程中想出一个伪设计。 Joel 在他的一篇文章中提到了这一点。
If the tasks seem un-estimable, I think the best approach would be to break down those tasks into smaller tasks that you can estimate. It might take several iterations, but you will probably come up with a pseudo design while you are at it. Joel mentions this in one of his articles.
将不可估计的任务拆分为消除不确定性的任务和“其余的”。通过概念验证测试或尖峰解决方案消除不确定性。要么安排本次冲刺的峰值，然后安排下一个冲刺的其余工作，要么将冲刺的开始推迟一周的峰值。
Split the unestimatable task into a task to remove the uncertainty, and "the rest". Remove uncertainty with Proof-of-concept tests or spike solutions. Either schedules the spikes this sprint and the rest of the work next sprint, Or delay the start of the sprint for a week of spiking.
我们通常不知道如何将故事分解为任务。在我们知道任务是什么之前，我们需要一段时间的探索。 “尖峰”似乎很难管理。其一，您可能无法限制发现周期。其次，如果不知道故事需要多长时间，我就无法有效地计划冲刺。
似乎另一种选择是在 Sprint 1 中完成峰值任务并在 Sprint 2 中完成任务。缺点是该过程似乎会强制工作不自然地崩溃。为什么这周发现然后等待一段时间再开始工作。
We often don't know enough to break a story down into tasks. We have a period of discovery before we know what the tasks will be. "Spikes" seem tricky to manage. For one, you may not be able to time box the discovery period. Second, I can't effectively plan a sprint without knowing how long a story will take.
Seems like another option is to do the spike in Sprint 1 and the tasks in Sprint 2. The downside is that it seems like the process forces an unnatural breakdown of the work. Why discover this week and then wait a while before starting the the work.
我们使用“特遣队”或特定的待办事项来完成此类任务。
Scrum 工具 Agilo 支持这种工作方式并计算这些问题，例如在《燃尽》中。通过这种方式，您可以很好地控制“不可计划”的项目。
We use "contingents" or a specific backlog for such tasks.
The Scrum Tool Agilo is supporting this way of working and calculates those issues too, e.g. in the Burndown. In this way you get a good control on the "un-plannable" items.
您是否混淆了精度和准确度？
敏捷估算背后的想法是得出一个足够好的数字，而不是一个精确的数字。这就是为什么使用故事点来估计积压项目是最佳实践；它强调努力/复杂性而不是持续时间。
您不需要知道在冲刺中实现待办事项列表项所需的每项任务需要多长时间。您需要知道的是，考虑到您之前在此冲刺中承诺的工作，您可以承诺此待办事项列表项吗？因为我们知道我们无法确切知道每个待办事项将花费多少时间，所以我们必须做出有根据的猜测。
更重要的是，Scrum 中的失败意味着什么？完成每个冲刺积压项目不是失败吗？不...如果您完成了五分之四，并且第五项已大部分完成，您将获得这四项已完成项目的积分（就冲刺的速度而言），并且当您完成该项目的剩余任务时未来冲刺中的第五个项目，您将获得该项目的全部学分。但是，如果您不使用 Scrum，您还能完成更多工作吗？ Scrum 中唯一的失败是无法从错误中吸取教训，不断重复做同样的功能失调的事情，同时却期待不同的结果。
因此，在您的冲刺计划会议中，不要花太多时间担心您无法知道的事情。让团队思考工作，然后让他们签署他们认为可以在冲刺期间完成的工作量。如果他们承诺不足，您可以随时将某些内容拖入待办事项列表中，或者提前结束冲刺。如果他们过度承诺，那么您可以按优先顺序完成积压的项目，并讨论为什么未完成的项目无法在冲刺回顾中完成，以及如何防止在未来的冲刺中出现未完成的项目。
顺便说一句，我知道这对你来说可能是一个糟糕的措辞，但是一个有效的 Scrum Master 不会运行冲刺。团队进行冲刺，Scrum Master 积极寻找降低其生产力并干扰其履行承诺能力的障碍。 Scrum Master 不是管理者，他们是裁判、教练和记分员的组合。他们是流程的守护者，帮助团队遵循流程，保护团队免受试图绕过流程的外部代理的影响，并通过确保更新冲刺待办事项和冲刺燃尽图来跟踪冲刺期间的进度反映日常生活中的现实。在您所描述的情况下，团队不确定他们应该签署多少工作，Scrum Master 应该让团队决定，以体现对团队承诺所有权的尊重。无论什么决定，都不会错。
Are you confusing precision with accuracy?
The idea behind Agile estimation is to come up with a number that is good enough, not a number that is exact. That is why using story points for backlog item estimation is a best practice; it emphasizes effort/complexity instead of duration.
You don't need to know how long each task necessary to implement a backlog item in a sprint will take. What you need to know is, given the work you've previously committed to in this sprint, can you commit to this backlog item? Because we know that we can't know exactly how much time each backlog item will take, we have to make an educated guess.
More important, what does it mean to fail in Scrum? Is not getting every sprint backlog item completed a failure? No... if you got four out of five items done and the fifth one is mostly done, you'll get credit for the four completed items (in terms of velocity for the sprint), and when you finish the remaining tasks for that fifth item in a future sprint you will get full credit for that item. But, would you have gotten any more done if you weren't using Scrum? The only failure in Scrum is failing to learn from your mistakes, to keep doing the same dysfunctional things repeatedly while expecting different results.
So, in your sprint planning meeting, don't spend a lot of time worrying about something you're not going to be able to know. Let the team think about the work, and then let them sign up for the amount of work they feel comfortable they can complete during the sprint. If they undercommit you can always drag something into the backlog, or end the sprint early. If they overcommit, then you finish the backlog items you can in priority order and discuss why the unfinished items couldn't be finished in the sprint retrospective, along with how to prevent having unfinished items in future sprints.
By the way, I know this was probably a poor choice of words on your part, but an effective Scrum Master doesn't run the sprint. The team runs the sprint, and the Scrum Master actively looks for impediments that lower their productivity and interfere with their ability to meet their commitments. Scrum Masters aren't managers, they're a combination of referee, coach, and scorekeeper. They are the Keeper of the Process, they help the team follow the process, they protect the team from outside agents that try to go around the process, and they track progress during the sprint via ensuring the sprint backlog is updated and the sprint burndown chart reflects reality, on a daily basis. In the situation you've described, where the team isn't sure how much work they should sign up for, the Scrum Master should let the team decide as a reflection of respect for team ownership of the commitment. Whatever the decision is, it won't be wrong.
尖峰应该有时间限制。它给团队带来了压力，要求他们限制范围并更好地了解研究所需的成本效益；也就是说，为了一项花费几美元的任务进行三天的研究是没有用的。
这也得到了莱瑟姆关于目标设定理论的研究的支持，他在其中专门解决了这个问题。
Spikes should be time boxed. It puts on pressure on the team to limit the scope and have a better idea on the cost-benefits that the research will entail; ie it is useless to carry out 3 days of research for a task which would cost a few bucks.
This is also backed up by Latham's work on Goal Setting Theory where he specifically tackles this issue.