Scrum Burndown问题 [英] Scrum Burndown issues

问题描述

我们已经使用Scrum大约9个月了，并且在很大程度上已经取得了成功。但是，我们的燃尽图很少看起来像模型图，而是更像是一个令人恐惧的过山车，伴随着呕吐而引起的攀爬和坠落。

We have been using Scrum for around 9 months and it has largely been successful. However our burndown charts rarely look like the 'model' charts, instead resembling more of a terrifying rollercoaster ride with some vomit inducing climbs and drops.

在sprint原型设计和设计之前花了更多的时间，但是我们似乎仍然在sprint期间发现比最初想象的更多的工作。注意：这是指满足积压要求所需的工作而不是首先考虑的事情，而不是我们为积压工作确定了新项目。

To try and combat this we are spending more time before the sprint prototyping and designing but we still seem to discover much more work during the sprint than initially thought. Note: By this I mean the work required to meet the backlog is more involved than first thought rather than we have identified new items for the backlog.

这是一个常见问题

我应该指出，我们的大部分开发工作都不是开创性的，因此我们将功能保持在现有的大型复杂应用程序。仅仅是因为您不知道现有代码将引发什么问题，scrum是否不适合这种类型的开发？

I should point out that most of our development work is not greenfield, so we are maintaining functionality in an existing large and complex application. Is scrum less suited to this type of development simply because you don't know what problems the existing code is going to throw up?

我们应该花多少时间？在sprint开始确定开发细节之前？

Just how much time should we be spending before the sprint starts working out the detail of the development?

更新：我们现在取得了更大的成功，并且行驶更加顺畅。这主要是因为我们在估计时采取了更为悲观的观点，这为我们在事情没有计划时处理事情提供了更多的喘息空间。您可以说它使我们更加敏捷。我们还试图改变这种看法，即燃尽图只是某种进度表，而不是范围v资源的指示。

UPDATE: We are having more success and a smoother ride now. This is largely because we have taken a more pessimistic view when estimating which is giving us more breathing space to deal with things when they dont go to plan. You could say its allowing us to be more 'agile'. We are also trying to change the perception that the burn down chart is some kind of schedule rather than an indication of scope v resources.

推荐答案

一些使事情变得顺利的技巧。

Some tips on smoothing things out.

1）正如其他人所说的那样，请尝试将任务分解为较小的块。更明显的方法是尝试更详细地分解技术任务。在可能的情况下，我鼓励您与产品负责人交谈，看看是否可以缩小范围或缩小故事。我发现后者更有效。如果团队和产品负责人都了解正在讨论的内容，那么轻而易举地调整优先级和估算就容易了。

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）尝试进行较短的冲刺。如果您要进行一个月的冲刺，请尝试两个星期。如果您要工作两个星期，请尝试一个星期。

2) Try doing shorter sprints. If you're doing one month sprints - try two weeks. If you're doing two weeks - try one.

• 这限制了故事的大小-鼓励产品负责人和团队工作在更容易准确估算的较小故事上


• 您可以获得更多关于估算的反馈-而且更容易看到在冲刺开始时做出的决策与实际决策之间的联系发生


• 实践使一切变得更好：-）

3）使用站立姿势并回顾更多地了解起伏的原因。是您花时间在代码库的特定区域上吗？是因为人们误解了产品所有者吗？随机的紧急情况使开发人员远离了团队？一旦您更加了解起伏在哪里，您通常可以专门解决这些问题。再次-短距离的冲刺可以使这一点更加明显。

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）相信自己的历史。您可能知道这个...但是我还是会说:-)如果摆弄那个可怕的传统Foo包比您认为的最后一次冲刺花费了3倍多的时间-那么它也将花费您认为的3倍下一个冲刺。不管您认为这次您的效率如何；-)相信历史，并使用昨天的天气之类的东西来指导您明年春季的估算。

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.

希望这会有所帮助！

这篇关于Scrum Burndown问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！