Scrum 燃尽图：任务还是故事？
在 Scrum 中制作燃尽图有多种方法。
有些人建议使用未完成故事的故事点作为 Scrum 中的燃尽图。
优点：只有完成的故事才会使图表下降
相反：图表一开始不会向下移动，然后迅速下降
其他人建议使用剩余的任务数量
优点：图表会向下移动，你可以看到它是否在终点线上方
反对：你可以向下移动说最后还剩下 10 个任务（困难任务），但仍然有没有一个故事讲完。 你失败了，因为只有完成的故事才对你的产品所有者有好处。
解决方案是否同时具有未完成故事点和未完成任务图表？
There are several ways to do burn down charts in Scrum.
Some people suggest using the story points of unfinished stories left as your burn down charts in Scrum.
Pro: Only finished stories lower the chart
Contra: Chart doesn't move down in the beginning and then rapidly falls off
Others suggest to use the number of tasks left
Pro: Chart will move down, you can see if it is above the finishing line
Contra: You could move down to say 10 tasks left (hard tasks) in the end, and still have not one story finished. You've failed because only finished strories are good for your product owner.
Is the solution to have both a points-of-not-finished-stories and a not-finished-task chart?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
我们使用剩余时间进行冲刺燃尽 - 团队每天都可以看到进展。 如果有平坦的部分，那么它们就真的出现了。
在发布燃尽图中，我们使用故事点。 发布计划更多的是关于功能的完整性，时间是在冲刺级别上跟踪的。 产品负责人对已完成的故事感兴趣。
任务数量没有用。 这个数字每天都可以改变，特别是如果你给开发者“自由”的话。 他们可以将任务分割成更小的部分，而不会改变总时间。 这样的统计是没有用的。 它说明什么？ 它会影响冲刺的目标吗？
We are using remainig time for sprint burndown - teams can see progress every day. If there are flat parts, than they really occured.
In the release burndown we are using story points. Release planning is more about he feature completness, the time is tracked on the sprint level. Product owner is interested in completed stories.
Number of tasks is useless. This number can be changed every day, especially if you give a "freedom" to developers. They can split the task to smaller part without the change of the total time. Such statistic is useless. What is it indicating? Does it affect the goal of the sprint?
在我看来，跟踪任务是一种相当次优的跟踪方法。 根据我的经验，一个故事很少真正是其任务的总和 - 而且通常，在实现一个故事时，我发现任务分解无论如何都是次优的。
而且，虽然我发现在评估故事时集思广益任务很有价值，但我更喜欢故事足够小，以至于根本没有跟踪它们的冲动。 事实上，为完成的任务而获得积分是非常具有误导性的，因为即使完成了所有已确定任务的一半，仍然不能保证冲刺将交付任何价值。 这就是利益相关者最终感兴趣的：实际交付的预计价值有多少？
因此，跟踪故事并进一步分解故事既可以提供更准确的反馈，又可以降低无法交付价值的风险。
实际上，在处理小故事时，我根本看不到 Sprint 燃尽图有多大价值 - 只需观看卡片墙上的故事从“待办事项”移动到“进行中”再到“完成”就应该给您带来一切您需要的信息。 不过，根据我的经验，发布烧毁可能非常有价值。
In my opinion, tracking tasks is a rather suboptimal approach to tracking. In my experience, a story seldom really is the sum of its tasks - and often, while implementing a story, I find that the task breakdown was suboptimal, anyway.
And, while I find value in brainstorming tasks while estimating a story, I prefer to have stories that are small enough that there is no urge to track them at all. In fact, getting credit for tasks finished is highly misleading, as having even half of all identified tasks finished still isn't any guarantee that the Sprint will deliver any value at all. And that's what the stakeholders are interested in in the end: how much of the projected value will be actually delivered?
So, tracking stories and working on further breaking down stories both gives more accurate feedback and reduces the risk of no value delivery.
Actually, when working with small stories, I don't see much value in Sprint burn down charts at all - just watching stories on the wall of cards move from "to do" to "in progress" to "done" should give you all the information you need. A Release burn down, though, that can be quite valuable, in my experience.
我们通常需要根据客户要求的故事跟踪时间（估计与实际与估计完成时间）。 这使我们能够做一些事情：
我们还跟踪已完成的故事以供我们自己的燃尽，但正如已经指出的那样，这可能会导致冲刺开始时的平台效应，从而无法告诉我们有用的信息（除了我们并行做得不够） ）。
We usually need to track hours (estimate vs actual vs estimate to complete) against stories for the clients who asked for them. This allows us to do a few things:
We also track completed stories for our own burndown, but as has been pointed out this can lead to a plateau effect at the start of the sprint that serves to tell us very little useful info (other than that we're not doing enough in parallel).
燃尽图（或什至“燃尽图”）应该仅表明剩余工作。
如果你完成了一个故事的一半，则无法发布它，并且它不算数。 如果你以一个半完成的故事结束了春天——如果你正在测量速度，那么在其中完成的任务就不算数。
只需绘制剩余故事需要完成的图表即可。
这是一个更严格的措施，但修改数字是没有用的——scrum 应该传达坏消息，以便问题得到解决。
Burndowns (or even "burn ups") should only indicate work remaining.
If you've half done a story you can't ship it, and it doesn't count. If you end the spring with a story half-done - tasks that were done in it don't count if you're measuring velocity.
Just chart stories left to be completed.
This is a tougher measure but there's no use massaging the figures - scrum is supposed to communicate bad news so that things will get fixed.
我们两者都做，就好像我们不包括任务一样，我们的生产线将会陷入停滞状态，看起来就像什么都没完成一样。
如果一个故事需要 2 天才能完成，那么这 2 天的线路是平坦的，并且无法判断团队是否按兵不动，或者工作量增加了（因此任务时间有所增加）。
当然，任务线可能会直线下降，而不会有助于完成故事，如果开发人员可以随意选择任务，则可能会出现这种反模式。
We do both, as if we didn't include tasks our line would plateau in a way that makes it look like nothing is getting done.
If a story takes 2 days to finish, then you have a flat line for 2 days, and there's no way to tell whether the team is sitting on their thumbs, or that work increased (thus a jump in task hours).
Of course the task line can plummet without contributing to finishing stories, which is an anti-pattern that can occur if developers can choose tasks at will.
跟踪剩余任务的数量并不是很有帮助，因为任务可能具有不同的大小。
你不应该发现自己处于团队完成十个任务但没有积压项目的情况（实际上，如果你有十个开发人员，这是可能的）：每个开发人员都不应该从另一个积压项目（故事）中获取任务，直到他完成积压工作他所做的第一个故事也属于 - 如果另一个故事的任务比开始的故事中的剩余任务更难的事件。
Tracking the number of remaining tasks is not very helpful as the tasks are likely to have different sizes.
You should not find yourself in a situation where the team complete ten tasks and no backlog item (actually, this is possible if you have ten developers) : every developer should not pick up tasks from another backlog item (story) until he completes the backlog item the first stories he did belongs too - event if the task form the other story is harder than the remaining tasks from the started sotry.
我用了很多“剩余时间”来进行燃尽。 团队总是发现按时间跟踪燃尽与时间跟踪系统接近，增加了管理开销，并且确实不准确，除非我们将人类转变为机器人。
我正在使用任务燃尽图（总任务、新任务、已完成的任务）。 好多了。 确实，您看不到已完成或新任务的大小。 但团队每天都会开会，这就是你发现问题的地方。 此外，我指导团队不要创建大任务（最多 4 到 6 小时）。 此外，我还添加了另一个图表，其中包含每日的新任务和已完成的任务。 团队发现按任务进行燃尽比使用时间更有意义。
在团队了解了在任务中分解故事的价值之后，我想尝试按故事进行燃尽。 因此，小故事最多有 5 或 8 个故事点。 Jeff Sutherland 博客表示，这是让团队实现高绩效的一大进步。
另外，我想提一下，燃尽图只是“进度的概览”。 对于团队和 PO 来说最重要、甚至更相关的是：每天提到的任务 + 故事进度百分比 + 障碍列表。 一段时间后，管理层和团队成员就不太关心燃尽（或烧毁）。
I used a lot the "hours remaining" for burndown. Team always find that tracking burndown by time is close to time tracking system, add overhead of administration and is really not accurate unless we transform humans to robots.
I am using tasks burndown (total tasks, new tasks, done tasks). Much much better. It is true that you do not see the size of the tasks that are done or new. But team meet everyday and that's where you catch problems. As well, I coach team to not create big tasks (4 to 6 hrs max). Also, I added an other chart with New tasks and Done tasks by day. Team found that the burndown by tasks make more sense that using hours.
After the team understand the values of breaking down stories in tasks, I want to try burndown by stories. So having small stories with a max of 5 or 8 story points. From Jeff Sutherland blog, this is a big step to get a team to high perform.
In addition, I'd like to mention that a burndown is just a "At a glance representation of progress". Most important and even more relevant for the team and PO's are: what is being mentioned in daily about the tasks + story progress percentages + list of impediments. After a while, management and team members don't care much about the burndown (or burn up).
我们使用任务是因为它提供了更多的粒度。 仅绘制故事的完成情况（我们每两周冲刺 5-10 个故事）只会显示每一两天的变化，并且正如您提到的，在冲刺开始时根本不会发生太大变化。
我的团队发现的另一件有用的事情是使用堆叠折线图，其中“待办事项”、“进行中”、“准备好进行质量检查”和“已验证”各用一行表示。 这样就可以轻松查看创建备份过程中的任何阶段。
We use tasks because it provides so much more granularity. Graphing only the completion of stories (which we do 5-10 per two-week sprint) will only show a change every day or two and, as you mention, won't move much at all during the beginning of the sprint.
Another useful thing my team has found is using a stacked line chart with one line for each of "To Do", "In Progress", "Ready for QA", and "Validated". This way it is easy to see any phase in the process that is creating a backup.
使用 Sprint 燃尽剩余时间
- 在冲刺计划期间，根据您对完成的定义估计完成故事所需的所有工作
- 每天，开发人员和测试人员都会重新估计所有工作的剩余时间（向上或向下变化）
- 通过剩余时间跟踪冲刺燃尽 - 很好地指示冲刺进展情况的好坏
这不适合发布燃尽，因为您不会分解待办事项中的所有故事，只分解冲刺计划研讨会中下一个冲刺的故事。 因此，请使用故事点燃尽图（整个团队在规划扑克会议期间得出的相对规模和复杂性值）。 这是释放进度的重要指标。
Use hours remaining for Sprint burndowns
- During sprint planning, estimate all the work to complete a story according to your definition of done
- Each day, developers and testers re-estimate the hours remaining for all their work (changing upwards or downwards)
- track the sprint burndown via Hours remaining - great indicator of how well or badly a Sprint is going
This is not appropriate for release burndowns as you do not breakdown all stories in the backlog, only those for the next sprint in the sprint planning workshop. So use Story point burndowns (relative size and complexity values derived by the whole team during planning poker sessions). This is a great indicator of progress towards your release.