Do you track time in Scrum as a function of hours/days spent on a task, or simply whether that task is complete or not?
I track the estimated remaining work. This is a must have information. Without this, you can't draw the Burndown Chart. Without the Burndown Chart, you don't know "where" you are, you don't know if your Sprint is still on track or not. This would make this decision tool pretty useless. Yes, the Burndown Chart is not a tracking tool, it's a decision tool.
Can you adjust those tasks and estimates?
Sure!
Actually, the team owns the estimates, nobody else, and it is the job of the ScrumMaster to guaranty that this principle is applied. This should already answer the question. But there are other reasons.
As I said, a Sprint Backlog and a Burndown chart are decision tools and should thus be representative of where you really are. If you hide the reality, if you are not transparent, these tools won't help you to take any valuable decision, they will be useless. Think about it, what's the point of having good looking numbers if they are useless? What's the point of having a "nice looking burndown" if it doesn't reflect the reality.
So, during a Sprint, team members should obviously update the estimations of the remaining work as soon as they can do it (upward or downward). If a task estimate was initially 6h but the team discovers that more work has to be done and that the task will actually take 8h, the team should update the Sprint Backlog accordingly. If someone spent 4h hours on a task that was initially estimated at 4h but still need 2h work, these 2h should be reported on the Sprint Backlog. If the team discovers a task that has to be done but that wasn't identified, the team must add this task and its estimate to the Sprint Backlog. And being not accurate in the start is not a problem, as long as you update the backlog with the knowledge gathered over time. The sooner you make these updates, the sooner you'll be able to adapt and take decisions.
That said, it can be useful to keep the "initial estimate" and to compare it to the "actual time spent to complete". But not for tracking purpose, only to help the team to make better estimates. Actually, I would advice to not do this if you are transitioning to Scrum. There are often many other impediments to solve, many other things to improve first when you are learning Scrum values and principles. And if you do it, beware of the Waterfall daemons. Be ready to fight them, they may come back very fast.
The answers I see here aren't wrong, but I don't think they've really addressed your question.
I think you're asking, "Should I track the total hours actually spent on a certain task?" The answer is, "You can if you need to, but it isn't part of Scrum."
Scrum is a very lightweight process. It defines/requires only what is needed to make Scrum work. You can (and, in many cases, probably should) overlay other processes on top of Scrum in order to suit your organizational needs. For example, if tracking the total hours actually spent on a task enables you to better estimate similar tasks in the future (as it seems your VP wants), then that might be a good reason to track total hours, provided that it doesn't interfere with productive work too much. Or, perhaps you need to know the total hours for billing purposes. So just because Scrum doesn't require something doesn't mean you shouldn't do it.
However, for the purposes of Scrum itself, there is no need to track the total hours actually spent on a task. It is not needed for any of the Scrum artifacts, which only track the estimated amount of time remaining.
I don't know if our implementation is "correct", but what we do is:
Have Backlog Items added, which we put an estimated complexity number on (in relation to other backlog items).
Before each sprint, we go through the backlog items in priority order (prioritized by the product owner), break them down into tasks for which we make a time estimate (in hours).
When the number of available hours in the sprint are used up, the sprint is full
Then, during the sprint after each day of work we adjust the times on the tasks that we have been working on, so that they show the number of hours that we think is left before the task is done. This means that if I have a 6 hour task, work on it for a full day (we consider 6 hours a full day) and then feel that I still have 2 hours left before it's done, then I take down the "hours left" from 6 to 2. In case the task is time-boxed we need to check actual hours used instead, of course.
but one of the things he has brought with him is the concept of very carefully quoting estimates of actual hours each task should require to complete, with the intention of getting more accurate with our estimates over time: thus once a project has started we cannot add new tasks or adjust the hourly estimates on those tasks.
Is just plain not scrum so I don't know where your VP got his info. Tasks (know as Sprint Backlog Items) are not created until Planning the next sprint. They are created just in time and certainly not before the project starts. Before the project starts (Sprint 0), the Product Owner creates the Product Backlog and fills it with stories. He can add to it at ANY time during the project. It is his to manage. The team estimates these stories roughly against one another in story points or some other relative measure (ideal days?).
The estimating of tasks in hours is only a tool the team uses to figure out how many stories to commit to in the sprint and then to plot progress to predict success (burndown). Once a team has gelled and has a historical velocity; it may decide to not do any tracking in hours at all and just track their burndown in story points or # of stories. Estimating in hours is a form of waste in itself if the team does not need it to achieve commitment to the sprint goals.
I would ask the VP what these "very careful" estimates are going to accomplish.
Estimate time, but don't really care if it's spot on
Just make sure you are careful and estimate tasks thoroughly. Basically you don't really measure time, because it's more error prone. The best way is to use tasks' time estimates as story points. This way you will gain:
If your time estimates are off, research shows that they tend to be consistently off (accuracy factor doesn't change too much), so time estimates can easily be used for story points calculation.
If you empirically managed to do x number of story points in previous sprint, you'll probably achieve similar results this time round even though your time estimates are incorrect.
You will have to be rather good at estimating all story tasks. Otherwise your sprint story points tend to grow during execution and you won't meet your deadline - even though your velocity will remain practically the same
Estimates can change but similar to #3, keep some sprint slack time for these changes to meet sprint deadlines (demo day).
But keep time estimates to actually see which tasks must split or join.
We track both the time spent working on the tasks, and the time remaining to complete them. The remaining time allows to determine the progress made during the Sprint, and to anticipate whether we will be able to achieve the Sprint goal. We update the remaining time for the tasks, adjusting it (sometimes increasing it) on a daily basis.
The time spent is - supposedly- for micro management. It also gives the team a chance to get some feedback on the accuracy of the estimates - and to get better at estimating - and to show how interruptions prevent the team to work on the Sprint backlog and therefore, slow it down.
In the Scrum process, individual deliverable goals are called Backlog Items, and can be seen as bucket of tasks. The Backlog Items are prioritized by the Product Owner, estimated by the Team, first as a whole and then task by task. Content, scope, priority and estimation of the Backlog Items can be revised.
We estimate both the Backlog Items and the tasks in time units (days or weeks for the Backlog Items, hours for the tasks) and we apply a focus factor (ratio of time dedicated to work solely on the Sprint tasks) to account for time not spent working on tasks to achieve the Sprint goal.
With respect to time tracking, what you're looking for is a burndown chart.
Fredrik explained what a burn down is, without using the term. Essentially, you regularly reestimate the time remaining for a particular activity.
So to your question of whether or not we track time spent, not necessarily. Scrum likes to work with time remaining instead. (You could substitute hours with story points, the principle is the same, as Robert explained.)
To your second question of whether you can adjust your tasks and estimates, most definitely yes. Agile follows the 'reactive to change' philosophy; you prioritize what's most important to the customer.
However, some teams to prefer not to add/delete/re-prioritize tasks in a particular sprint once it's begun, since that is almost an ad-hoc way of working, and even scrum requires some structure and discipline.
The statement "thus once a project has started we cannot add new tasks or adjust the hourly estimates on those tasks." is almost certainly not in the spirit of agile.
We use the Pomodoro Technique to track the time remaining. One of its advantages is that the amount of time spent is recorded in a disciplined way.
After estimating stories in story points, we estimate tasks in terms of pomodori, and use this estimate (which may be reestimated ad hoc) to judge the amount of time remaining. At the end of the sprint it's easy to see which tasks we originally estimated the least accurately and improve how we estimate in the future, due to the way we mark the number of pomodori estimated and completed on each post-it.
In terms of the sprint, the estimated hours remaining are just a measure of progress so we can see where we are burndown-wise. They're a clue to whether we're on track or not. The score that matters is story points completed.
By definition, an item is done when all of the tasks that need to be completed in order to fully implement that item have 0 hours left. What you need to track inside the sprint is remaining hours on remaining tasks. Not hours spent on a task. Why? Because our knowledge of how long something will take is imperfect and we gain little by trying to come up with a super-accurate estimate when we should be working on the product.
You are always allowed to add tasks under a sprint backlog item as you identify more work that must be done to fully implement the item, and you should update the remaining hours to completion daily (or set them to 0 once you've completed the task).
You should tell your VP that knowing when you're going to ship the product based upon your most accurate information (today) is far better than setting a number/making an estimate in the past and never updating it. This doesn't mean re-estimating user stories (don't do that until the end of the release), it means updating the sprint backlog with new tasks, and the best estimate as to when active tasks will be complete in remaining hours.
BTW, the way to work on accurate estimates is to plan your release using story points, create an iteration plan based upon your estimated team velocity, and then to continually update the iteration plan based upon the output at the end of each sprint. After a very few sprints you will get a very accurate idea of the actual team velocity, making it easy to forecast when you will ship your release with the desired scope... or what scope should be completed by the original ship date. Using actual project data from your current project to predict project completion is a software engineering best practice, because it is the most accurate way to make a prediction.
发布评论
评论（9）
我跟踪预计剩余工作。这是必须具备的信息。没有这个，你就无法绘制燃尽图。没有燃尽图，您不知道自己在“哪里”，也不知道 Sprint 是否仍在正轨上。这将使这个决策工具变得毫无用处。是的，燃尽图不是跟踪工具，而是决策工具。
当然！
实际上，团队拥有估算，没有其他人，ScrumMaster 的工作就是保证这一原则得到应用。这应该已经回答了这个问题。但还有其他原因。
正如我所说，冲刺待办事项列表和燃尽图是决策工具，因此应该代表您的实际情况。如果你隐藏现实，如果你不透明，这些工具将无法帮助你做出任何有价值的决定，它们将毫无用处。大家想一想，如果数字再好看又有什么用呢？如果“好看的烧毁”不能反映现实，那么它有什么意义呢？
因此，在冲刺期间，团队成员显然应该尽快更新剩余工作的估计（向上或向下）。如果任务最初估计需要 6 小时，但团队发现需要完成更多工作并且该任务实际上需要 8 小时，则团队应相应更新 Sprint Backlog。如果某人花了 4 小时完成最初估计需要 4 小时但仍需要 2 小时工作的任务，则应在 Sprint 待办事项列表中报告这 2 小时。如果团队发现一项必须完成但尚未确定的任务，则团队必须将此任务及其估计添加到 Sprint 待办事项列表中。只要您使用随着时间的推移收集的知识来更新积压工作，一开始就不准确也不是问题。您越早进行这些更新，您就能越早适应并做出决定。
也就是说，保留“初始估计”并将其与“实际完成时间”进行比较可能很有用。但不用于跟踪目的，只是为了帮助团队做出更好的估计。实际上，如果您要过渡到 Scrum，我建议不要这样做。当您学习 Scrum 价值观和原则时，通常还有许多其他障碍需要解决，许多其他事情需要首先改进。如果你这样做，请小心瀑布守护进程。准备好与他们战斗，他们可能很快就会回来。
I track the estimated remaining work. This is a must have information. Without this, you can't draw the Burndown Chart. Without the Burndown Chart, you don't know "where" you are, you don't know if your Sprint is still on track or not. This would make this decision tool pretty useless. Yes, the Burndown Chart is not a tracking tool, it's a decision tool.
Sure!
Actually, the team owns the estimates, nobody else, and it is the job of the ScrumMaster to guaranty that this principle is applied. This should already answer the question. But there are other reasons.
As I said, a Sprint Backlog and a Burndown chart are decision tools and should thus be representative of where you really are. If you hide the reality, if you are not transparent, these tools won't help you to take any valuable decision, they will be useless. Think about it, what's the point of having good looking numbers if they are useless? What's the point of having a "nice looking burndown" if it doesn't reflect the reality.
So, during a Sprint, team members should obviously update the estimations of the remaining work as soon as they can do it (upward or downward). If a task estimate was initially 6h but the team discovers that more work has to be done and that the task will actually take 8h, the team should update the Sprint Backlog accordingly. If someone spent 4h hours on a task that was initially estimated at 4h but still need 2h work, these 2h should be reported on the Sprint Backlog. If the team discovers a task that has to be done but that wasn't identified, the team must add this task and its estimate to the Sprint Backlog. And being not accurate in the start is not a problem, as long as you update the backlog with the knowledge gathered over time. The sooner you make these updates, the sooner you'll be able to adapt and take decisions.
That said, it can be useful to keep the "initial estimate" and to compare it to the "actual time spent to complete". But not for tracking purpose, only to help the team to make better estimates. Actually, I would advice to not do this if you are transitioning to Scrum. There are often many other impediments to solve, many other things to improve first when you are learning Scrum values and principles. And if you do it, beware of the Waterfall daemons. Be ready to fight them, they may come back very fast.
我在这里看到的答案并没有错，但我认为它们并没有真正解决你的问题。
我想您是在问：“我应该跟踪某项任务实际花费的总时间吗？”答案是：“如果需要的话可以，但这不是 Scrum 的一部分。”
Scrum 是一个非常轻量级的过程。它仅定义/需要使 Scrum 工作所需的内容。您可以（并且在许多情况下，可能应该）在 Scrum 之上叠加其他流程，以满足您的组织需求。例如，如果跟踪实际花费在某项任务上的总时间使您能够更好地估计将来的类似任务（正如您的副总裁所希望的那样），那么这可能是跟踪总时间的一个很好的理由，前提是它不过多干扰生产性工作。或者，您可能需要了解总小时数以进行计费。因此，仅仅因为 Scrum 不需要某些东西并不意味着您不应该这样做。
然而，就 Scrum 本身而言，无需跟踪任务实际花费的总时间。任何 Scrum 工件都不需要它，它们只跟踪估计的剩余时间量。
The answers I see here aren't wrong, but I don't think they've really addressed your question.
I think you're asking, "Should I track the total hours actually spent on a certain task?" The answer is, "You can if you need to, but it isn't part of Scrum."
Scrum is a very lightweight process. It defines/requires only what is needed to make Scrum work. You can (and, in many cases, probably should) overlay other processes on top of Scrum in order to suit your organizational needs. For example, if tracking the total hours actually spent on a task enables you to better estimate similar tasks in the future (as it seems your VP wants), then that might be a good reason to track total hours, provided that it doesn't interfere with productive work too much. Or, perhaps you need to know the total hours for billing purposes. So just because Scrum doesn't require something doesn't mean you shouldn't do it.
However, for the purposes of Scrum itself, there is no need to track the total hours actually spent on a task. It is not needed for any of the Scrum artifacts, which only track the estimated amount of time remaining.
我不知道我们的实现是否“正确”，但我们所做的是：
然后，在每天工作后的 sprint 期间，我们调整我们一直在处理的任务的时间，以便它们显示需要完成的小时数。我们认为在任务完成之前就剩下了。这意味着，如果我有一个 6 小时的任务，工作一整天（我们考虑一整天 6 小时），然后觉得我还剩下 2 小时才能完成，那么我记下“剩余时间”从 6 到 2。如果任务有时间限制，我们当然需要检查实际使用的时间。
I don't know if our implementation is "correct", but what we do is:
Then, during the sprint after each day of work we adjust the times on the tasks that we have been working on, so that they show the number of hours that we think is left before the task is done. This means that if I have a 6 hour task, work on it for a full day (we consider 6 hours a full day) and then feel that I still have 2 hours left before it's done, then I take down the "hours left" from 6 to 2. In case the task is time-boxed we need to check actual hours used instead, of course.
我必须在这里添加一些东西，因为
只是简单的不是 scrum，所以我不知道你的副总裁从哪里得到他的信息。在规划下一个冲刺之前，不会创建任务（称为冲刺待办事项列表项）。它们是及时创建的，当然不是在项目开始之前创建的。在项目开始（Sprint 0）之前，产品负责人创建产品待办事项列表并在其中填充故事。他可以在项目期间随时添加内容。是他来管理的。团队根据故事点或其他一些相对衡量标准（理想的日子？）粗略地估计这些故事。
以小时为单位估算任务只是团队用来确定冲刺中要提交多少个故事，然后绘制进度以预测成功（燃尽）的工具。一旦团队凝聚起来并达到历史速度；它可能决定根本不在几个小时内进行任何跟踪，而只跟踪故事点或故事数量的燃尽情况。如果团队不需要它来实现对冲刺目标的承诺，那么以小时为单位进行估算本身就是一种浪费。
我会问副总裁这些“非常仔细”的估计将实现什么目标。
I have to add something here because
Is just plain not scrum so I don't know where your VP got his info. Tasks (know as Sprint Backlog Items) are not created until Planning the next sprint. They are created just in time and certainly not before the project starts. Before the project starts (Sprint 0), the Product Owner creates the Product Backlog and fills it with stories. He can add to it at ANY time during the project. It is his to manage. The team estimates these stories roughly against one another in story points or some other relative measure (ideal days?).
The estimating of tasks in hours is only a tool the team uses to figure out how many stories to commit to in the sprint and then to plot progress to predict success (burndown). Once a team has gelled and has a historical velocity; it may decide to not do any tracking in hours at all and just track their burndown in story points or # of stories. Estimating in hours is a form of waste in itself if the team does not need it to achieve commitment to the sprint goals.
I would ask the VP what these "very careful" estimates are going to accomplish.
估计时间，但并不关心它是否准确。
只要确保你小心并彻底估计任务即可。基本上你并没有真正测量时间，因为它更容易出错。最好的方法是使用任务的时间估计作为故事点。通过这种方式，您将获得以下好处：
但要保留时间估计，以实际查看哪些任务必须拆分或合并。
Estimate time, but don't really care if it's spot on
Just make sure you are careful and estimate tasks thoroughly. Basically you don't really measure time, because it's more error prone. The best way is to use tasks' time estimates as story points. This way you will gain:
But keep time estimates to actually see which tasks must split or join.
我们跟踪完成任务所花费的时间以及完成任务的剩余时间。剩余时间可以用来确定 Sprint 期间取得的进展，并预测我们是否能够实现 Sprint 目标。我们更新任务的剩余时间，每天调整它（有时增加它）。
据推测，所花费的时间用于微观管理。它还使团队有机会获得有关估算准确性的一些反馈，从而更好地进行估算，并展示中断如何阻碍团队处理 Sprint 积压工作，从而减慢进度。
在 Scrum 流程中，各个可交付目标称为待办事项列表项，可以将其视为任务桶。待办事项列表项目由产品负责人确定优先级，由团队评估，首先作为一个整体，然后逐个任务。待办事项的内容、范围、优先级和估计可以修改。
我们以时间单位（待办事项的天数或周，任务的小时数）来估计待办事项和任务，并应用焦点因素（专门用于 Sprint 任务的时间比例）来考虑不考虑的时间。花在实现 Sprint 目标的任务上。
We track both the time spent working on the tasks, and the time remaining to complete them. The remaining time allows to determine the progress made during the Sprint, and to anticipate whether we will be able to achieve the Sprint goal. We update the remaining time for the tasks, adjusting it (sometimes increasing it) on a daily basis.
The time spent is - supposedly- for micro management. It also gives the team a chance to get some feedback on the accuracy of the estimates - and to get better at estimating - and to show how interruptions prevent the team to work on the Sprint backlog and therefore, slow it down.
In the Scrum process, individual deliverable goals are called Backlog Items, and can be seen as bucket of tasks. The Backlog Items are prioritized by the Product Owner, estimated by the Team, first as a whole and then task by task. Content, scope, priority and estimation of the Backlog Items can be revised.
We estimate both the Backlog Items and the tasks in time units (days or weeks for the Backlog Items, hours for the tasks) and we apply a focus factor (ratio of time dedicated to work solely on the Sprint tasks) to account for time not spent working on tasks to achieve the Sprint goal.
关于时间跟踪，您需要的是燃尽图。
Fredrik 解释了烧毁是什么，但没有使用这个术语。本质上，您定期重新估计特定活动的剩余时间。
因此，对于我们是否跟踪花费的时间的问题，不一定。 Scrum 喜欢利用剩余时间来工作。 （你可以用故事点代替时间，原理是一样的，正如罗伯特解释的那样。）
对于你是否可以调整任务和估计的第二个问题，绝对可以。敏捷遵循“响应变化”的理念；您优先考虑对客户最重要的事情。
然而，一些团队不愿意在特定的冲刺开始后添加/删除/重新确定任务的优先级，因为这几乎是一种临时的工作方式，甚至 Scrum 也需要一些结构和纪律。
该声明“因此，一旦项目开始，我们就无法添加新任务或调整这些任务的每小时估算。”几乎可以肯定，这不符合敏捷精神。
With respect to time tracking, what you're looking for is a burndown chart.
Fredrik explained what a burn down is, without using the term. Essentially, you regularly reestimate the time remaining for a particular activity.
So to your question of whether or not we track time spent, not necessarily. Scrum likes to work with time remaining instead. (You could substitute hours with story points, the principle is the same, as Robert explained.)
To your second question of whether you can adjust your tasks and estimates, most definitely yes. Agile follows the 'reactive to change' philosophy; you prioritize what's most important to the customer.
However, some teams to prefer not to add/delete/re-prioritize tasks in a particular sprint once it's begun, since that is almost an ad-hoc way of working, and even scrum requires some structure and discipline.
The statement "thus once a project has started we cannot add new tasks or adjust the hourly estimates on those tasks." is almost certainly not in the spirit of agile.
我们使用番茄工作法来跟踪剩余时间。其优点之一是以严格的方式记录所花费的时间。
在按故事点估计故事后，我们根据番茄时间估计任务，并使用此估计（可能会临时重新估计）来判断剩余时间量。在冲刺结束时，由于我们在每个便利贴上标记估计和完成的番茄工作数的方式，很容易看出我们最初估计的最不准确的任务，并改进我们未来的估计方式。
就冲刺而言，估计的剩余时间只是进度的衡量标准，因此我们可以看到我们的燃尽情况。它们是我们是否走上正轨的线索。重要的分数是完成的故事点。
We use the Pomodoro Technique to track the time remaining. One of its advantages is that the amount of time spent is recorded in a disciplined way.
After estimating stories in story points, we estimate tasks in terms of pomodori, and use this estimate (which may be reestimated ad hoc) to judge the amount of time remaining. At the end of the sprint it's easy to see which tasks we originally estimated the least accurately and improve how we estimate in the future, due to the way we mark the number of pomodori estimated and completed on each post-it.
In terms of the sprint, the estimated hours remaining are just a measure of progress so we can see where we are burndown-wise. They're a clue to whether we're on track or not. The score that matters is story points completed.
根据定义，当为了完全实施该项目而需要完成的所有任务还剩 0 小时时，该项目就完成了。您需要在冲刺中跟踪剩余任务的剩余时间。不是花在一项任务上的时间。为什么？因为我们对某件事情需要多长时间的了解并不完善，并且试图对何时应该开发该产品进行超准确的估计几乎没有什么收获。
当您发现需要完成更多工作才能完全实施该项目时，您始终可以在冲刺积压项目下添加任务，并且您应该每天更新剩余时间以完成（或在完成任务后将其设置为 0） ）。
您应该告诉您的副总裁，根据您最准确的信息（今天）知道您将何时发货，比过去设定一个数字/进行估计而不更新它要好得多。这并不意味着重新估计用户故事（在发布结束之前不要这样做），而是意味着用新任务更新冲刺积压工作，以及对活动任务何时在剩余时间内完成的最佳估计。
顺便说一句，准确估计的方法是使用故事点来规划您的发布，根据您估计的团队速度创建迭代计划，然后根据每个冲刺结束时的输出不断更新迭代计划。经过几次冲刺后，您将对实际团队速度有一个非常准确的了解，从而可以轻松预测何时将发布具有所需范围的版本……或者应在原始发布日期之前完成哪些范围。使用当前项目中的实际项目数据来预测项目完成情况是软件工程最佳实践，因为它是进行预测的最准确方法。
By definition, an item is done when all of the tasks that need to be completed in order to fully implement that item have 0 hours left. What you need to track inside the sprint is remaining hours on remaining tasks. Not hours spent on a task. Why? Because our knowledge of how long something will take is imperfect and we gain little by trying to come up with a super-accurate estimate when we should be working on the product.
You are always allowed to add tasks under a sprint backlog item as you identify more work that must be done to fully implement the item, and you should update the remaining hours to completion daily (or set them to 0 once you've completed the task).
You should tell your VP that knowing when you're going to ship the product based upon your most accurate information (today) is far better than setting a number/making an estimate in the past and never updating it. This doesn't mean re-estimating user stories (don't do that until the end of the release), it means updating the sprint backlog with new tasks, and the best estimate as to when active tasks will be complete in remaining hours.
BTW, the way to work on accurate estimates is to plan your release using story points, create an iteration plan based upon your estimated team velocity, and then to continually update the iteration plan based upon the output at the end of each sprint. After a very few sprints you will get a very accurate idea of the actual team velocity, making it easy to forecast when you will ship your release with the desired scope... or what scope should be completed by the original ship date. Using actual project data from your current project to predict project completion is a software engineering best practice, because it is the most accurate way to make a prediction.