Scrum Burndown问题

我们已经使用Scrum大约9个月了,它已基本成功.然而,我们的燃尽图很少看起来像"模型"图表,而是更像是一个可怕的过山车乘坐,有些呕吐物引起攀爬和跌落.

为了尝试和解决这个问题,我们在sprint原型设计和设计之前花费了更多的时间,但我们似乎仍然在sprint中发现了比最初想象的更多的工作.注意:我的意思是,遇到积压所需的工作比最初想到的更为复杂,而不是我们已经为积压确定了新项目.

这是Scrum的常见问题,是否有人有任何提示可以帮助顺利驾驶？

我应该指出,我们的大部分开发工作都不是绿地,因此我们在现有的大型复杂应用程序中维护功能.Scrum是否不适合这种类型的开发只是因为您不知道现有代码会引起什么问题？

在sprint开始计算开发细节之前,我们应该花多少时间？

更新:我们现在取得了更大的成功和更顺畅的旅程.这很大程度上是因为我们在估算时采取了更为悲观的观点,即当他们不去计划时,这给了我们更多的喘息空间来处理事情.你可以说它让我们变得更加"敏捷".我们还试图改变这样的看法,即烧毁图表是某种时间表而不是范围v资源的指示.

有关平滑事物的一些提示.

1)正如其他人所说的那样 - 尝试将任务分解成更小的块.更明显的做法是尝试更详细地分解技术任务.在可能的情况下,我鼓励您与产品所有者交谈,看看您是否可以缩小范围或"减薄"故事.我发现后者更有效.如果团队和产品所有者都了解正在讨论的内容,那么更容易处理优先事项和估算.

我的一般经验法则是任何估计大于理想日的一半可能是错误的:-)

2)尝试做更短的冲刺.如果你正在做一个月的短跑 - 试试两周.如果你做了两个星期 - 试试一个.

它可以限制故事大小 - 鼓励产品所有者和团队处理更容易准确估计的小故事

您可以更频繁地获得有关估算的反馈 - 并且更容易看到您在冲刺开始时做出的决策与实际发生的事情之间的联系

练习一切都变得更好:-)

3)使用站立和回顾来更多地了解起伏的原因.是时候花时间在代码库的特定区域？是民间误解产品所有者造成的吗？随机紧急情况会使开发时间远离团队？一旦你有了更多了解起伏起伏的地方,你就可以经常解决这些问题.再次 - 较短的冲刺可以帮助使这更明显.

4)相信你的历史.你可能知道这个......但我会说反正:-)如果与可怕遗留的Foo包摆弄了3×的时间比你想象的还要持续冲刺 - 那么它也将采取3×只要你想下一个冲刺.无论你认为这次会有多么有效;-)相信历史,并使用昨天的天气来指导你在明年春天的估计.

希望这可以帮助!