当你的scrum团队提前完成sprint的工作时,接受更多工作的官方规则/指南是什么?

时间:2011-03-29 16:17:02

标签: agile scrum

具体来说,如果您只接受新工作,您知道团队可以在给定的迭代中完成吗?即使您知道团队没有时间完成它,也可以启动下一个优先级最高的积压项目吗?谢谢!

11 个答案:

答案 0 :(得分:15)

我们利用时间来修复错误,并偿还一些技术债务。

如果您可以在不与产品所有者交谈的情况下执行此操作,则取决于您对Scrum的理解或与产品所有者的工作安排。

在我个人看来,你对冲刺做出了承诺。你的部分交易是履行承诺。另一方面,产品负责人应该没有技术资源,因为这是开发人员擅长的。技术债务是技术性的东西。虫子可能是。但最终你必须与PO达成共识,你可以自己决定什么以及你需要咨询PO。在理想的世界中,开发人员非常了解产品,他们可以自己做出决定。

从下一个项目开始当然是另一种选择。如果你无法完成它,Lex Scrum说不要碰它。我在某种程度上喜欢这个定律,因为它实际上会产生一些可以被开发人员好用的松弛......比如修复错误和偿还技术债务。如果实现另一个故事是最好的利用你的时间:找到一个你可以完成的。如果你找不到/创建一个,这实际上是你刚刚找到的障碍。假设我们至少在谈论2-3个开发人员的4小时这样的事情,我们真的应该找到一些有用的东西来实现这些资源,不是吗?

答案 1 :(得分:6)

  

你应该只接受你知道团队可以在给定的迭代中完成的新工作吗?即使您知道团队没有时间完成它,也可以启动下一个优先级最高的积压项目吗?

记住“个人和流程与工具之间的互动”做你的常识告诉你的事情。不要过于关注工具和流程。

根据Scrum指南,团队承诺的工作量完全取决于团队。

当完成上面的所有项目时,启动下一个最高优先级项目没有任何害处。然而,最好将物品分解成更小或更薄的切片,这实际上可以完成。

如果团队提前完成了所有的积压项目,那么团队肯定会占用更多。

答案 2 :(得分:5)

我会采取积压中的下一个最高项目,并与产品所有者合作创建一个可以在此次迭代中完成的故事...所以将故事分解为更小的尺寸以适应。

答案 3 :(得分:3)

我们没有采取新的工作,无论是否可以在冲刺内完成。您应该专注于Technical DebtDesign DebtCode Debt

答案 4 :(得分:2)

绝对将故事分解为合适的东西。团队应 从不 承诺无法在sprint中完成的任务。此外,只有团队才能添加新作品。如果团队提前完成,团队需要与产品负责人合作并同意将工作添加到sprint。当“领导”甚至Scrummaster开始与团队以外的产品负责人谈判时,我看到团队陷入困境。

答案 5 :(得分:1)

为了明确回答这个问题,Scrum说您应该与产品负责人协商,并接受额外的工作。

Scrum做得很好,Scrum团队每天都会检查他们的进度,所以你应该在实际发生之前看到早期预测的方式,给你足够的时间与产品负责人聊聊Sprint的内容。

Scrum做得好也让Scrum团队在进入Sprint之前准备好用户故事(通过Sprint规划和产品Backlog改进),因此需要将用户故事分解为更小的组件,以便他们能够适应Sprint大大减少了。

答案 6 :(得分:0)

你可以把一个故事分成一个小故事,这样你就可以在当前的冲刺中处理它,或者你可以将一个故事非正式地分成两个冲刺,把它的一些任务推迟到下一个。

请记住,敏捷归结为找到满足团队需求的最佳方式,而不是遵循结构化规则。

答案 7 :(得分:0)

无论你走哪条路,我都会去团队,问他们他们想要什么,或者认为他们应该做什么。请记住,在Scrum中,我们重视自我管理团队。 对于建议,如果他们感到难过,我会说做以下其中一项:

  • 减少技术债务
  • 利用时间学习有价值的东西
  • 让团队选择"Gold Card"。他们准时,他们可能赢得了它。
  • 将下一个故事分成更小(但仍然有意义)的故事,第一个故事可以在冲刺结束时及时完成。
  • 如果下一个故事无法如上所述完成,请及时完成 的下一个故事。

希望这有帮助,
阿萨弗。

答案 8 :(得分:0)

这是我的团队所做的事情 -

首先,由团队决定他们可以在sprint的剩余部分中进行哪些额外的工作。整个团队对此进行投票至关重要,而不仅仅是开发人员。

其次,如果团队决定他们可以处理X个更多的工作点,那么他们会转到PO并确认积压项目的优先级,并找到一个或多个总结为该X点的故事。有时他们不得不在积压的情况下向下移动以寻找适合的积压。只要PO在最终选择中没问题,团队就会继续推进新工作。

第三,无论团队选择的新工作与原始工作具有相同的承诺水平。冲刺结束时任何部分完成的故事都失败了。

最后,在计划下一个冲刺时,速度会向上调整(在这种情况下),因为团队很可能在开始时选择不足的工作。这是一个关键点 - 速度应始终反映团队根据他们的工作能力最近的历史记录进行的最佳猜测。如果PO看到团队提前完成并前往其他非积压工作,这可能会导致PO和团队之间的信任问题。只要有讨论和协议,与团队一起决定专注于技术债务(尽管我认为这些仍然是需要测试工作的故事)或其他项目完全没问题。

答案 9 :(得分:0)

我认为一个承诺不足的冲刺的解决方案可能是阻止冲刺。如果团队完成了工作,那么冲刺就结束了。在sprint backlog中添加更多故事的另一个选择是风险太大,团队很少100%确定他们可以处理所有额外的工作。 据我所知,没有规定(比如说,2周)冲刺不能提前2或3天结束。

答案 10 :(得分:0)

我认为这是你需要在一些冲刺之后进行观察的事情。如果您在冲刺结束时经常离开业余时间,那么您应该承诺在计划会议中做更多的工作。

如果很少发生这种情况,我当然要注意不要在积压的情况下定期添加任务。除非你做了一些体面的积压修饰,否则他们不太可能成为他们第一次出现的快速胜利。你也想避免一个漫长的迷你计划会议,因为那些你有空的日子可能很快就会消失 - 特别是如果你包括那些有未完成任务的开发人员的观点。

无论如何,通过减少技术债务或积压修饰等来寻求通过下一个冲刺来取得进步,但是通过承诺上班迟到让自己陷入困境并不值得努力。