The people actually doing the work estimate the cost involved. If you are using raw time as a metric for estimation, Agile methodologies frown on it. Your team should be using an abstraction to estimate cost, such as 'points'. You can start with a rough baseline of 1 hour per point with a minimum of 1 point. Then developers can make raw estimates of how long something should take. Slap them or anyone else on the wrist if they talk in hours or in any other unit of time.
The point is that as development moves along through multiple sprints, project managers can adjust 'point' time estimates provided by the team to match reality -- This can even be done per individual developer. Participants will become better and better at estimation as projects progress. So, since Sprints are an iterative process, time estimates improve with more iterations.
This begs another question: Why are you worried about time? Time is basically cost in the Waterfall model. In Agile, the goal is developing software to VALUE not cost. The reason points are used is that it is an abstract basis of comparison that business owners, project managers and creators (developers) can all view in an abstract light. (Unbiased from different participants' cultural, social or psychological perceptions of time.) Business owners can take a look at available points in a given sprint -- and knowing the points available -- they can elect functionality that is most important. It is always a bit of a tough decision, but again, the goal is to develop toward value and away from time boxing or feature stuffing.
"Who should be coming up with the time estimate for a task and when does this happen?" Depends on how you run your team. Do you let the team members truly self-manage, so tasks are assigned when a person grabs it during the sprint? You may have to keep using the time to complete based on the abilities of an average developer on the team. Do you have a team lead that assigns the tasks to people as they are created during the Sprint Planning meeting? Let the person assigned estimate the time to complete the task.
I agree removing time from the effort estimate is a bit confusing. The big question is: what does it matter that you are overestimating the task time? Is the team sitting around for 4-5 days at the end of a sprint with nothing to do? If so, go to the Product Owner and let her know the team wants to add one or two small items into the Sprint. You don't normally add stuff to an ongoing sprint, but Scrum is a framework to manage work, and as long as the team signs off on adding the new items, there is no need not to let Scrum work for your team....not force your team to work for Scrum.
Also, your questions seems to indicate your team has a greater velocity than what is being planned. If your 2-week sprint (10 work days) has a velocity of 10, but your team is getting finished with everything by day 7, just up your story points on the next sprint to 11 or 12.
发布评论
评论（2）
实际从事这项工作的人会估算所涉及的成本。如果您使用原始时间作为估计指标，敏捷方法论会对此不以为然。您的团队应该使用抽象来估计成本，例如“点”。您可以从每点 1 小时的粗略基线开始，最少 1 分。然后开发人员可以对某件事应该花费多长时间进行原始估计。如果他们以小时或任何其他时间单位说话，请拍拍他们或其他任何人的手腕。
关键是，随着开发通过多个冲刺进行，项目经理可以调整团队提供的“点”时间估计以匹配现实——这甚至可以由每个开发人员完成。随着项目的进展，参与者的估算能力会越来越好。因此，由于 Sprint 是一个迭代过程，因此时间估算会随着迭代次数的增加而改进。
这就引出了另一个问题：你为什么担心时间？在瀑布模型中，时间基本上就是成本。在敏捷中，目标是开发软件以实现价值而不是成本。之所以使用点，是因为它是一个抽象的比较基础，企业主、项目经理和创建者（开发者）都可以用抽象的眼光来看待。 （不受不同参与者对时间的文化、社会或心理认知的影响。）企业主可以查看给定冲刺中的可用点 - 并且了解可用点 - 他们可以选择最重要的功能。这总是一个有点艰难的决定，但同样，目标是朝着价值发展，远离时间限制或功能填充。
The people actually doing the work estimate the cost involved. If you are using raw time as a metric for estimation, Agile methodologies frown on it. Your team should be using an abstraction to estimate cost, such as 'points'. You can start with a rough baseline of 1 hour per point with a minimum of 1 point. Then developers can make raw estimates of how long something should take. Slap them or anyone else on the wrist if they talk in hours or in any other unit of time.
The point is that as development moves along through multiple sprints, project managers can adjust 'point' time estimates provided by the team to match reality -- This can even be done per individual developer. Participants will become better and better at estimation as projects progress. So, since Sprints are an iterative process, time estimates improve with more iterations.
This begs another question: Why are you worried about time? Time is basically cost in the Waterfall model. In Agile, the goal is developing software to VALUE not cost. The reason points are used is that it is an abstract basis of comparison that business owners, project managers and creators (developers) can all view in an abstract light. (Unbiased from different participants' cultural, social or psychological perceptions of time.) Business owners can take a look at available points in a given sprint -- and knowing the points available -- they can elect functionality that is most important. It is always a bit of a tough decision, but again, the goal is to develop toward value and away from time boxing or feature stuffing.
“谁应该提出任务的时间估计以及什么时候发生？”取决于你如何管理你的团队。你是否让团队成员真正进行自我管理，以便在冲刺期间有人抓住任务时分配任务？您可能必须根据团队中平均开发人员的能力继续利用时间来完成。您是否有团队负责人在冲刺计划会议期间将任务分配给创建的人员？让分配的人估计完成任务的时间。
我同意从工作量估计中删除时间有点令人困惑。最大的问题是：你高估了任务时间有什么关系？团队是否在冲刺结束时坐了 4-5 天无所事事？如果是这样，请去找产品负责人，让她知道团队想要在 Sprint 中添加一两个小项目。您通常不会向正在进行的冲刺添加内容，但 Scrum 是一个管理工作的框架，只要团队同意添加新项目，就没有必要不让 Scrum 为您的团队工作...... .不要强迫你的团队为 Scrum 工作。
此外，您的问题似乎表明您的团队的速度比计划的要快。如果您的 2 周冲刺（10 个工作日）的速度为 10，但您的团队在第 7 天完成了所有工作，则只需将下一个冲刺的故事点提高到 11 或 12。
"Who should be coming up with the time estimate for a task and when does this happen?" Depends on how you run your team. Do you let the team members truly self-manage, so tasks are assigned when a person grabs it during the sprint? You may have to keep using the time to complete based on the abilities of an average developer on the team. Do you have a team lead that assigns the tasks to people as they are created during the Sprint Planning meeting? Let the person assigned estimate the time to complete the task.
I agree removing time from the effort estimate is a bit confusing. The big question is: what does it matter that you are overestimating the task time? Is the team sitting around for 4-5 days at the end of a sprint with nothing to do? If so, go to the Product Owner and let her know the team wants to add one or two small items into the Sprint. You don't normally add stuff to an ongoing sprint, but Scrum is a framework to manage work, and as long as the team signs off on adding the new items, there is no need not to let Scrum work for your team....not force your team to work for Scrum.
Also, your questions seems to indicate your team has a greater velocity than what is being planned. If your 2-week sprint (10 work days) has a velocity of 10, but your team is getting finished with everything by day 7, just up your story points on the next sprint to 11 or 12.