This is as it should be. If your burndown chart looks like the model chart, you're in trouble. The chart will help to see if you will be able to make you commitment and finish all the stories.
Discovering stories during the sprint will always happen. Ideally you would be able to design and find out the tasks up front but if they worked why would a big upfront design not work? To answer you last question, the sprint planning should take at most four hours.
We are using a 'time-boxed' task for unplanned tasks. Whenever high-priority work is coming, or sudden bugs pop up, we can use time of the time-box (but, we can never go under zero). This method has the additional advantage that we can easily track which tasks were unforeseen, and keep those things into account during our next sprint planning.
We are now using a burn UP chart. Instead of just charting the amount of work left we chart two things: the amount of work completed and the total amount of work (ie. completed + outstanding).
This gives you two lines on the graph that should meet when all the work is done. It also has a big advantage in that it clearly shows when progress is slow because more work has been added.
If you like, the PO 'owns' one line (the total work) and the developers/testers 'own' the other line (work done).
The PO's line will go up and down as they add/remove work.
The dev/tester line will only go up as they complete work.
I had similar problems in my burndown as well. I "fixed" it by refining what was included in the burndown.
SiKeep commented:
Its progress against the backlog selected for that sprint, which may or may not end up as a release.
Since you selected certain things for the sprint and that's what is on the burndown, I don't know that all the "new work" should appear in the burndown. I would see it going onto the backlog (not affecting the burndown), unless it's important enough to move into your current sprint (which would then show up as an upward trend in the burndown).
That said, minor up's and down's are normal, if the trendline basically follows your expected velocity. I would be concerned about the roller-coaster trend you're mentioning. However, the idea of isolating the burndown by only adding high priority items to the current sprint may help dampen these up and downs on your burndown.
As others have said, the planning before the sprint starts should be short...(no more than 4 hours).
I have had similar issues. My previous team (on it for over a year) was large and we maintained a very large, rapidly changing codebase for series of initial product launches. Our burndowns were shameful looking, but it was the best we could ever do.
One thing that may help (make your graph look better) is stick to the number of hours/points committed to constant. If you have underestimated a task, and have to double hours, pull something out of the sprint. If you pull in a new task, it's obviously of higher priority than something your team committed to so pull that other thing out.
We tried the breaking up the task into many tasks in and before planning, and that never seemed to help. In fact, it just gave us more damn tickets to keep track of during the sprint. Requirements started migrating to the tickets and (not surprisingly) got lost in all the shuffle.
On my new team we took a pretty radical approach and started creating big tickets (some over a week long) that say things like "implement v1.2 features in ProjectX." The requirements/feature lists for ProjectX (version 1.2 included) are kept on a wiki so the ticket is very clean and only tracks the work performed. This has helped us a lot - we have way fewer tickets to keep track of, and have been able to finish all our sprints even though we keep getting pulled off our sprint tasks to help other teams or put out fires.
We continue to push items out of the sprint if (and only if) we are forced (by the man) to bring in new items.
Another simple tip that helped us: add "total hours in sprint" to your burndown. This should be the sum of all estimates. Working on keeping this line flat may help, and increases visibility of the problems your team may be facing (assuming that won't get you demoted...)
As others have said, I would expect a burndown to be up and down. Stuff happens! You should use the "up and down" bits as fodder for your retrospectives.
Make sure everyone is clear on what "being done" means, and use that joint understanding to help drive your planning sessions. Often having a list of what constitutes done available will (a) help you remember things you might forget and (b) will likely trigger more ideas for tasks that would otherwise surface later on.
One other point to think about - if you are working month on month with an unpredictable codebase, I would still expect your velocity to normalise out to a reasonably steady rate. Just track your success against your planned work and only use completed items as a maximum when planning. Then focus on your unplanned tasks and see if there are any patterns that suggest there are things you can do differently to include those things in the planned work.
1) As others have said - try and break down the tasks into smaller chunks. The more obvious way of doing this is to try and break down the technical tasks in greater detail. Where possible I'd encourage you to talk to the product owner and see if you can reduce scope or "thin" the story instead. I find the latter more effective. Juggling priorities and estimates is easier if both team and product owner understand what's being discussed.
My general rule of thumb is any estimate bigger than half an ideal day is probably wrong :-)
2) Try doing shorter sprints. If you're doing one month sprints - try two weeks. If you're doing two weeks - try one.
It acts a limiter on story size - encouraging the product owner and the team to work on smaller stories that are easier to estimate accurately
You get feedback more often about your estimates - and it's easier to see the connections between the decisions you made at the start of the sprint and what actually happened
Everything gets better with practice :-)
3) Use the stand ups and retrospectives to look a bit more at the reasons for the ups and downs. Is it when you spend time with particular areas of the code base? Is it caused by folk misunderstanding the product owner? Random emergencies that take development time away from the team? Once you have more of an understanding where ups and downs are coming from you can often address those problems specifically. Again - shorter sprints can help make this more obvious.
4) Believe your history. You probably know this one... but I'll say it anyway :-) If fiddling with that ghastly legacy Foo package took 3 x longer than you thought it would last sprint - then it will also take 3 x as long as you think the next sprint. No matter how much more effective you think you'll be this time ;-) Trust the history and use things like Yesterday's Weather to guide your estimates in the next spring.
I am happy to hear that scrum has been largely successful for you - that is more important than having the sprint burndown chart look ideal. The sprint burndown is just a tool for the team to help it know if it is on track for the sprint goals. if the team has been meeting the sprint goals, I would not worry too much that the chart looks like a roller coaster. A few suggestions
During the sprint retrospective ask the team where the additional work is coming from
Extra work can come from not having good acceptance tests early in the sprint
Extra work can come from not having a well groomed backlog. A good rule of thumb is to spend at least 5% of the team's time thinking about the next sprint's stories ahead of time.
Monitor work in progress - is the team doing too much in parallel?
During sprint planning - how does the team feel about the breakdown of tasks that make up the stories?
If you have not been meeting sprint goals - use the established team velocity to take on less during the next sprint. You have to get good at walking before you can run.
In my experience, Scrum is definitely geared more towards new development than it is towards maintenance. New development is much more predictable than maintaining an old, large code base.
With that said, one possible problem is that you're not breaking up the tasks into small enough chunks. A common problem people have with software planning in general is that they think "oh, this task should take me 2 days" without really thinking about what goes into doing that task. Often, you'll find that if you sit down and think about it that task consists of doing A, B, C, and D and winds up being more than 2 days of work.
发布评论
评论（11）
文章这是您的燃尽图吗？ 解释了燃尽图中给定状态的含义。 它还提供了如何处理的建议。
本文中描述的一些示例：
Article Is it your burn down chart? explains what given status in burn down chart means. It also provides suggestions what to do with that.
Some examples described in the article:
这是应该的。 如果您的燃尽图看起来像模型图，那么您就有麻烦了。 该图表将帮助您了解您是否能够做出承诺并完成所有故事。
在冲刺期间发现故事总是会发生。 理想情况下，您能够预先设计并找出任务，但如果它们有效，为什么大型的预先设计不起作用呢？
为了回答您的最后一个问题，冲刺计划应该最多四个小时。
This is as it should be. If your burndown chart looks like the model chart, you're in trouble. The chart will help to see if you will be able to make you commitment and finish all the stories.
Discovering stories during the sprint will always happen. Ideally you would be able to design and find out the tasks up front but if they worked why would a big upfront design not work?
To answer you last question, the sprint planning should take at most four hours.
我们对计划外任务使用“限时”任务。 每当高优先级工作到来或突然出现错误时，我们都可以使用时间盒的时间（但是，我们永远不能低于零）。
这种方法还有一个额外的优点，那就是我们可以轻松跟踪哪些任务是不可预见的，并在下一个冲刺计划中将这些事情考虑在内。
We are using a 'time-boxed' task for unplanned tasks. Whenever high-priority work is coming, or sudden bugs pop up, we can use time of the time-box (but, we can never go under zero).
This method has the additional advantage that we can easily track which tasks were unforeseen, and keep those things into account during our next sprint planning.
您可以在冲刺的开始日期整合新工作，以获得漂亮的燃尽图。
您可以使用特定标记来标记额外的工作，并在冲刺结束时评估您之前无法识别这些任务的原因。
You can integrate the new work at the sprint's start date, to have a great looking Burndown chart.
You can tag with a specific marker the additional work and evaluate at the sprint's end why you haven't be able to identify those tasks before.
我们现在使用burn UP图表。 我们不只是绘制剩余工作量，而是绘制两件事：已完成的工作量和总工作量（即已完成+未完成）。
这会在图表上为您提供两条线，当所有工作完成后，两条线应该相交。 它还具有一个很大的优势，因为它可以清楚地显示何时进度缓慢，因为添加了更多工作。
如果您愿意，PO“拥有”一条线（全部工作），而开发人员/测试人员“拥有”另一条线（已完成的工作）。
当采购订单添加/删除工作时，其行会上下移动。
开发/测试人员线只会在他们完成工作后才会上升。
We are now using a burn UP chart. Instead of just charting the amount of work left we chart two things: the amount of work completed and the total amount of work (ie. completed + outstanding).
This gives you two lines on the graph that should meet when all the work is done. It also has a big advantage in that it clearly shows when progress is slow because more work has been added.
If you like, the PO 'owns' one line (the total work) and the developers/testers 'own' the other line (work done).
The PO's line will go up and down as they add/remove work.
The dev/tester line will only go up as they complete work.
我在倦怠中也遇到了类似的问题。 我通过改进燃尽图中包含的内容来“修复”它。
SiKeep 评论道：
由于您为冲刺选择了某些内容，并且这就是燃尽图上的内容，因此我不知道所有“新工作”都应该出现在燃尽图中。 我会看到它进入积压工作（不影响燃尽），除非它足够重要，可以进入当前的冲刺（然后在燃尽中显示为上升趋势）。
也就是说，如果趋势线基本上遵循您的预期速度，小幅上涨和下跌是正常的。 我会担心你提到的过山车趋势。 然而，通过仅向当前冲刺添加高优先级项目来隔离燃尽的想法可能有助于抑制燃尽的波动。
正如其他人所说，冲刺开始前的计划应该很短......（不超过 4 小时< /a>）。
I had similar problems in my burndown as well. I "fixed" it by refining what was included in the burndown.
SiKeep commented:
Since you selected certain things for the sprint and that's what is on the burndown, I don't know that all the "new work" should appear in the burndown. I would see it going onto the backlog (not affecting the burndown), unless it's important enough to move into your current sprint (which would then show up as an upward trend in the burndown).
That said, minor up's and down's are normal, if the trendline basically follows your expected velocity. I would be concerned about the roller-coaster trend you're mentioning. However, the idea of isolating the burndown by only adding high priority items to the current sprint may help dampen these up and downs on your burndown.
As others have said, the planning before the sprint starts should be short...(no more than 4 hours).
我也遇到过类似的问题。 我之前的团队（在这方面工作了一年多）规模很大，我们为一系列初始产品发布维护了一个非常庞大、快速变化的代码库。 我们的烧毁看起来很可耻，但这是我们能做的最好的事情。
可能有帮助的一件事（让你的图表看起来更好）是坚持保持恒定的小时数/点数。 如果您低估了一项任务，并且必须加倍工作时间，请从冲刺中提取一些内容。 如果您引入了一项新任务，那么它显然比您的团队承诺的任务具有更高的优先级，因此可以将其他任务拉出来。
我们尝试在计划中和计划之前将任务分解为许多任务，但这似乎没有帮助。 事实上，它只是给了我们更多该死的票来在冲刺期间跟踪。 需求开始转移到门票上，并且（毫不奇怪）在所有的混乱中迷失了。
在我的新团队中，我们采取了相当激进的方法，开始创建大票（有些长达一周多），上面写着“在 ProjectX 中实现 v1.2 功能”之类的内容。 ProjectX（包括版本 1.2）的要求/功能列表保存在 wiki 上，因此票证非常干净，仅跟踪所执行的工作。 这对我们帮助很大 - 我们需要跟踪的票数少了很多，并且能够完成所有的冲刺，即使我们不断地完成冲刺任务以帮助其他团队或淘汰火灾。
当（且仅当）我们被迫（被人）引入新项目时，我们才会继续将项目从冲刺中推出。
另一个对我们有帮助的简单技巧是：将“冲刺总时间”添加到你的燃尽图中。 这应该是所有估计值的总和。 努力保持这条线平坦可能会有所帮助，并提高您的团队可能面临的问题的可见性（假设这不会让您降职......）
-ab
I have had similar issues. My previous team (on it for over a year) was large and we maintained a very large, rapidly changing codebase for series of initial product launches. Our burndowns were shameful looking, but it was the best we could ever do.
One thing that may help (make your graph look better) is stick to the number of hours/points committed to constant. If you have underestimated a task, and have to double hours, pull something out of the sprint. If you pull in a new task, it's obviously of higher priority than something your team committed to so pull that other thing out.
We tried the breaking up the task into many tasks in and before planning, and that never seemed to help. In fact, it just gave us more damn tickets to keep track of during the sprint. Requirements started migrating to the tickets and (not surprisingly) got lost in all the shuffle.
On my new team we took a pretty radical approach and started creating big tickets (some over a week long) that say things like "implement v1.2 features in ProjectX." The requirements/feature lists for ProjectX (version 1.2 included) are kept on a wiki so the ticket is very clean and only tracks the work performed. This has helped us a lot - we have way fewer tickets to keep track of, and have been able to finish all our sprints even though we keep getting pulled off our sprint tasks to help other teams or put out fires.
We continue to push items out of the sprint if (and only if) we are forced (by the man) to bring in new items.
Another simple tip that helped us: add "total hours in sprint" to your burndown. This should be the sum of all estimates. Working on keeping this line flat may help, and increases visibility of the problems your team may be facing (assuming that won't get you demoted...)
-ab
正如其他人所说，我预计烧毁会是上下的。 出事了！ 您应该使用“向上和向下”的部分作为回顾的素材。
确保每个人都清楚“正在完成”的含义，并利用这种共同理解来帮助推动您的计划会议。 通常，列出可用的已完成内容将（a）帮助您记住可能忘记的事情，（b）可能会激发更多关于稍后会出现的任务的想法。
需要考虑的另一点是，如果您月复一月地使用不可预测的代码库工作，我仍然希望您的速度正常化到相当稳定的速度。 只需根据计划的工作跟踪您的成功情况，并在计划时仅使用已完成的项目作为最大数量。 然后专注于计划外的任务，看看是否有任何模式表明您可以采取不同的措施，将这些事情纳入计划的工作中。
As others have said, I would expect a burndown to be up and down. Stuff happens! You should use the "up and down" bits as fodder for your retrospectives.
Make sure everyone is clear on what "being done" means, and use that joint understanding to help drive your planning sessions. Often having a list of what constitutes done available will (a) help you remember things you might forget and (b) will likely trigger more ideas for tasks that would otherwise surface later on.
One other point to think about - if you are working month on month with an unpredictable codebase, I would still expect your velocity to normalise out to a reasonably steady rate. Just track your success against your planned work and only use completed items as a maximum when planning. Then focus on your unplanned tasks and see if there are any patterns that suggest there are things you can do differently to include those things in the planned work.
一些让事情变得顺利的技巧。
1）正如其他人所说 - 尝试将任务分解为更小的块。 更明显的方法是尝试更详细地分解技术任务。 如果可能的话，我鼓励您与产品负责人交谈，看看是否可以缩小范围或“精简”故事。 我发现后者更有效。 如果团队和产品负责人都了解正在讨论的内容，那么处理优先级和估计就会更容易。
我的一般经验法则是任何大于理想一天一半的估计都可能是错误的:-)
2) 尝试进行更短的冲刺。 如果您正在进行一个月的冲刺 - 尝试两周。 如果你准备两周——尝试一周。
3) 利用站会和回顾来更多地了解起伏的原因。 是当您花时间研究代码库的特定区域时吗？ 是因为人们对产品负责人的误解造成的吗？ 随机的紧急情况会占用团队的开发时间吗？ 一旦您对起起落落有更多的了解，您通常可以专门解决这些问题。 再次强调——较短的冲刺可以让这一点变得更加明显。
4）相信你的历史。 你可能知道这个......但无论如何我都会说:-)如果摆弄那个可怕的遗留 Foo 包花费的时间比你想象的持续冲刺时间长 3 倍 - 那么它也将花费你想象的 3 倍的时间下一个冲刺。 无论您认为这次的效率有多高；-) 相信历史并使用“昨天的天气”等信息来指导您对明年春天的估计。
希望这可以帮助！
Some tips on smoothing things out.
1) As others have said - try and break down the tasks into smaller chunks. The more obvious way of doing this is to try and break down the technical tasks in greater detail. Where possible I'd encourage you to talk to the product owner and see if you can reduce scope or "thin" the story instead. I find the latter more effective. Juggling priorities and estimates is easier if both team and product owner understand what's being discussed.
My general rule of thumb is any estimate bigger than half an ideal day is probably wrong :-)
2) Try doing shorter sprints. If you're doing one month sprints - try two weeks. If you're doing two weeks - try one.
3) Use the stand ups and retrospectives to look a bit more at the reasons for the ups and downs. Is it when you spend time with particular areas of the code base? Is it caused by folk misunderstanding the product owner? Random emergencies that take development time away from the team? Once you have more of an understanding where ups and downs are coming from you can often address those problems specifically. Again - shorter sprints can help make this more obvious.
4) Believe your history. You probably know this one... but I'll say it anyway :-) If fiddling with that ghastly legacy Foo package took 3 x longer than you thought it would last sprint - then it will also take 3 x as long as you think the next sprint. No matter how much more effective you think you'll be this time ;-) Trust the history and use things like Yesterday's Weather to guide your estimates in the next spring.
Hope this helps!
我很高兴听到 Scrum 对您来说取得了很大的成功——这比让 sprint 燃尽图看起来理想更重要。 冲刺燃尽图只是团队的一个工具，可以帮助团队了解是否正在实现冲刺目标。 如果团队已经实现了冲刺目标，我就不会太担心图表看起来像过山车。 一些建议
如果您尚未实现冲刺目标，请使用既定的团队速度在下一个冲刺期间减少承担。 在你能跑之前，你必须先学会走路。
I am happy to hear that scrum has been largely successful for you - that is more important than having the sprint burndown chart look ideal. The sprint burndown is just a tool for the team to help it know if it is on track for the sprint goals. if the team has been meeting the sprint goals, I would not worry too much that the chart looks like a roller coaster. A few suggestions
If you have not been meeting sprint goals - use the established team velocity to take on less during the next sprint. You have to get good at walking before you can run.
根据我的经验，Scrum 肯定更适合新开发而不是维护。 新的开发比维护旧的大型代码库更可预测。
话虽如此，一个可能的问题是您没有将任务分解成足够小的块。 人们在进行软件规划时遇到的一个常见问题是，他们认为“哦，这个任务应该需要我 2 天的时间”，而没有真正考虑完成该任务需要做什么。 通常，您会发现，如果您坐下来思考一下，该任务由 A、B、C 和 D 组成，最终需要超过 2 天的工作时间。
In my experience, Scrum is definitely geared more towards new development than it is towards maintenance. New development is much more predictable than maintaining an old, large code base.
With that said, one possible problem is that you're not breaking up the tasks into small enough chunks. A common problem people have with software planning in general is that they think "oh, this task should take me 2 days" without really thinking about what goes into doing that task. Often, you'll find that if you sit down and think about it that task consists of doing A, B, C, and D and winds up being more than 2 days of work.