Scrum论坛

嗨Dravid,

不,时间盒Sprint结束时到期。未完成Sprint待办事项列表中的待办项回到产品待办事项列表,可以解决在接下来的冲刺。

这是比扩展因为冲刺
——团队可以获得更好的估计
——降低复杂性的Scrum事件的一致性(不需要重新安排会议等等)。
——也许一个Sprint Backlog条目是足够大了10冲刺,所以通过扩展冲刺你不会工作敏捷了

scrum的建议,继续冲刺的dev明白他们能够在给定的时间框架,剩下的产品回日志吗

假设你延长了冲刺,你能负担得起扩展它多少钱?

您可以扩展但然后你失去大部分的责任和改进的机会。如果你一直修改冲刺时间你失去写故事的能力有效地管理订单,估计努力和失去个人责任。的时间段存在问责和帮助每个角色学习和发展。如果sprint长度变化来测量速度变得非常困难。最好恢复未完成项目积压,给团队一次机会选择他们的工作。这是一个很好的学习经历。

Scrum的美妙之处在于专注于人民和他们的行为。团队选择工作而不是分配工作。这是巨大的!计划驱动的方法失败由于缺乏来自团队成员的支持。团队知道前期的最后期限。如果他们不打他们的里程碑用它来重新审视这项工作是如何选择和估计的。交流和培训!如果你不,错过了冲刺的最后期限可能变得司空见惯。

Scrum指导是很清楚的:你不延长冲刺。最后的冲刺,如果有不完整的工作:“不完整的产品待办事项列表中的待办项都重新评估,把产品待办事项列表”。但这并不一定意味着sprint失败,按Scrum指南:“如果开发团队决定了过多或过少的工作,它可能协商选定的产品待办事项列表中的待办项与产品所有者”。同时在sprint:“范围可能澄清,产品所有者和开发团队之间的重新协议是后天习得的。"

不得不重新安排Sprint审查会议将阻止我延长一个Sprint时间盒,因为它可能很难得到适当的利益相关者对新会议(这可能不是一个问题对非常小的公司但对任何规模的公司来说,必要的利益相关者可能有各种各样的承诺,其他会议/项目/问题等)。

唯一一次我将改变冲刺时间盒,如果结果不匹配的需求的产品。例如,如果scrum团队选择了一个月的冲刺时间盒,和这个不允许增强/特性添加到产品市场足够快跟上竞争产品/公司,有可能是好的理由改变时间盒。但这应该是一个一次性的决定,不是从sprint-to-sprint不等。

这意味着任何扩展的主题先生

你会怎么做当有障碍发现在sprint中,没有办法完成这项工作吗?例如,数据需要的不是在任何数据库由于业务流程上的差距。你关闭用户故事吗?也,你烧了剩余的闲置时间,因为用户故事不能做吗?

我只是遇到了这个问题。有一个主要的产品待办事项列表项仍然是部分完成,大约75%。这是我第一次sprint和我一组两个(在这点上)所以我有一些灵活性,打破规则(这一次),因此,我只是进行编码,我们说话(后我完成这个评论:))。我进行的原因是这是一个相当复杂的功能,需要一个像样的大量使用代码的重构和停止现在,回来以后会花费很多时间来刷新内存的布线。对我来说,这是我不能浪费时间在正式re-adding回PB,回到它几天后。但我学到了一些教训,比如将来)磨练我们的估计精度和b),有时它可能意义获取更高的冲刺点这样的项目早在冲刺,而不是首先抓住低挂水果,然后达到更高的最后冲刺点项目。在未来有更大的团队我很可能保持scrum结构(而不是打破规则)和投机冲刺+ 1但是使它名列第一,回到正确的检查和回顾。

杰夫,

周围几个要点我想提高你的文章:

• 首先,它是一个很好的迹象,你看着一个不受欢迎的结果在一个sprint(未完成的项目),并确定了几个选项希望减轻它今后再次发生的可能性。这不仅反映了实证方法来工作(检查/调整),但也反映了持续改进的承诺,这是一个关键属性Agile-ly任何人希望工作
  
• 其次,重要的是,在Scrum中,根本就没有%完整的概念。项目是“完成”或“不做”。也许有点Yoda-ish,但这仍然是一个Scrum的关键特性

嗨Dravid,

你的问题不容易回答,因为有很多因素,你必须考虑你的决定,事实上,根据这本书,你应该完成冲刺,但如果你有一个新版本计划或这是一个非常重要的产品,您应该验证与您的团队,如果他们认为它可能获得它在几天,是方便等价值的产品给你的客户。我们应该记住,超出了纯粹主义的方法,最重要的是向客户交付价值。

致以最亲切的问候

爱德华多Hdez

我假设没有完成项目重新评估工作可能已经开始,未知现在将知道意思工作量可能会减少或实际上,提高吗?

我假设没有完成项目重新评估工作可能已经开始,未知现在将知道意思工作量可能会减少或实际上,提高吗?

这当然是可能的。喜欢很多东西,产品待办事项列表中的待办项可以,而且应该受到正在进行的检查和适应。

我假设没有完成项目重新评估工作可能已经开始,未知现在将知道意思工作量可能会减少或实际上,提高吗?

我有团队,不重新评估时进行。他们发现,保持原来的估计给他们更多的信息,当他们开始回顾评估过程。例如,如果一个团队估计是5,最终以1.5冲刺完成,有一个讨论他们如何虚实。发现,他们没想到是什么?那么未来会出现在他们的未来相对估计。他们估计基于实际发生后他们最初的估计。它一直很好,他们估计已经改善了不少。他们试着重新评估,发现它很难比较。你估计的基础上,结合数字因为你重新评估基于过去估计剩余的工作或者是基于使用?

让团队决定什么是最好的。是的,Scrum指南说,估计应该存在,但除了一个引用“估计”是专注于产品待办事项列表。如果一个故事从一个Sprint Backlog带到下一个Sprint Backlog,估计真的需要吗?最后,团队应该决定什么最适合他们。

如果一个故事从一个Sprint Backlog带到下一个Sprint Backlog,估计真的需要吗?

我唯一的评论这种方法丹尼尔(我认为我们之前讨论过的),选择不重新评估项目进行短跑冲刺可以降低透明度为剩下的项目/工作的实际大小。

但你还提到了(我完全同意),它应该留给Scrum团队来确定最适合他们。

@Timothy,你是对的。我们有讨论这不止一次。其实我更喜欢“不要重新评估”方法。但是,正如我有团队不重新评估,我有他们。我甚至在Sprint团队将重新评估而不是等待Sprint的界限。所有的团队都是有效的。

我有时让我偏好云我的评论。这就是为什么我总是注意添加“史上最佳的工作团队”,“这是我的意见”。我已经做一些长期反应。如果我真的试图掩盖一切我觉得/思考每个问题,我不妨开一个博客网站和文章链接。:)

也不会重新评估工作倾斜团队在接下来的冲刺的速度;例如,考虑这一块的工作几乎是“完成”,大部分的工作是进行最后的冲刺。估计5点努力,开发团队估计只剩下1分的努力完成工作,它进入Sprint Backlog和一到两天内完成下一个Sprint开始,只有1分的精力消耗,但价值的工作是5。这将被拉大sprint团队的速度。

达伦,我相信就是意见的差异所在。

一些喜欢放弃重新评估项目进行,有利于节省的费用re-estimation,让全部的数量要“归功于”完成后,这促进了“速度=努力”的观点。

其他人更愿意重新评估项目进行,有利于促进透明度的实际大小项目预测在接下来的冲刺,和促进“速度=完成”的观点。

几个事情要牢记:

• 故事点只有从规划的角度值。一旦sprint开始,不再重要的点(除非评估de-scope物品是否适应新的sprint待办事项列表中的待办项)
• Scrum指南是关于这种不规范的。开发团队只需要能够评估他们可以实现在即将到来的冲刺,他们更喜欢使用任何工具/数据/方法

排除的原因……如果团队不完成工作计划在冲刺,这被认为是技术债务吗?。

是的,不完整的工作将回到积压,后将采取行动,这些行动之一将是确定当悬而未决的工作将完成,这就是我认为技术债务的概念符合。

对我来说,技术债务不仅代表工作或工作完成后交付(如问题)它也可以代表工作即将完成…想法吗?

你认为技术债务之间的关系可能是“完成”的定义?

国防部可以被审查,正在发生的东西变成障碍的一组团队完成工作在sprint计划. .但最后的工作是不完整的……所以团队可以最终在短跑技术债务之间。

我有团队服务用户和那些不。我可以从我的经验和观察说,大小似乎提供了一个经验优势。

有趣的注意,“估计”和“估计”不再被引用2020年的指南的一部分。这是“大小”和“大小”所取代。

让我们来谈谈工作的实施。

Sprint backlog只有真的存在的上下文中创建的冲刺。当一个冲刺完成后,相关的Sprint backlog应该解散和被替换为一个新的下一个Sprint目标相吻合的。

团队可能会选择继续不完整的前一个Sprint工作,但这不应该是一个。如果我们工作经验,我们可能检查的东西使我们的优先权转变(市场变化为例),虽然工作已经开始,它可能更有意义被搁置支持适应更高的优先级。

想到的一些问题:

• 透明度,如何检验和适应影响当只携带工作向前没有讨论和大小吗?我们如何把我们从最后冲刺?
• 为什么大小(本质上是一个猜)从之前的Sprint所以有价值的,它应该被锁定在和维护?
• 可能从回顾PBI的更新的大小,超过冲刺完成吗?

我说我不想重新评估是有用的。然而,基于重新评估的讨论剩下的工作。如果一个团队想要改变最初估计的5到13占由于发现额外的工作,我可以支持。我也可以支持将当前项标记为“完成”,如果它符合“完成”的定义,是一个有价值的增量的一部分。在这种情况下我建议新票产品待办事项列表中创建代表剩余的工作,就像对待任何其他项目。

我提倡,无论采取的方法是一个团队,应该发生在回顾讨论这种情况发生的原因。谈话往往导致决定如何管理的问题。这也使得团队努力独立对待每个实例而不是创建一个为如何处理每次设定规则。

在我看来,估计只有有用的预测工作多少开发者觉得他们可以拉到一个冲刺。但我也提倡,它不是唯一的测量工具。看板的吞吐量指标、周期时间和工作可以是有价值的,有时候更有价值。这些指标是基于实际的工作,而不是想让基于知识有限。

我已经说过了,这是每个Scrum团队应该讨论和处理。我相信经验主义发挥作用,如果每一个场合讨论了独立于其他人,然后概括了。我不相信在陈述过程中如何处理这种情况,除非它是“我们将讨论,学习和适应每一次”。

大家好!

1. 这不是好的延长时间盒的事件,所以请不要。
2. 如果你的团队没有按时交付PBI (Sprint结束),作为一个SM你应该了解一些要点:

团队意识到他们什么时候不会达到Sprint目标(或它的一部分)?一半的冲刺呢?在Sprint结束吗?时间在Scrum中是非常重要的(阅读至关重要的)。

你做什么工作不浪费时间(精益思想)?你检查和透明度和适应。你怎么做呢?每日例会,燃尽图,其他指标。如果团队意识到任何障碍或“并发症”Sprint Backlog,他们可以重新协商订单可以在Sprint结束时没有交货延误。有些团队称之为Sprint backlog细化。

祝你有美好的一天,一周,一年!希望你们都很健康。

你好,

首先我变得快乐,有其他团队和SM和我有同样的问题。我做了仪表板Jira上展示了故事冲刺状态,保持一天的冲刺,热图sprint的状态。在所有的日常我们审查董事会和仪表板,但非不帮助完成至少90%的冲刺任务。尽管在每个规划我问开发人员仔细检查sprint backlog和如果他们太多,不选择他们。sprint中他们可以自由地把sprint backlog。这个解决方案的,没有解决的问题。

在所有的日常我们审查董事会和仪表板,但非不帮助完成至少90%的冲刺任务

如果会议冲刺阶段的目标,并带来了至少一个有用的,有价值的,和做的产品增量,也许并没有什么错90% ?

我问开发人员仔细检查sprint backlog和如果他们太多,不选择他们。sprint中他们可以自由地把sprint backlog。这个解决方案的,没有解决的问题

也许对于开发人员解决问题直接影响了他们的自我管理能力提出了自己的解决方案。为什么限制的解决方案只是自己,用团队的智慧吗?Scrum Master促进对话,可以一面镜子团队,教的冲刺目标,Scrum价值观,和做增量,但不应规定解决方案。

Scrum在

我认为,团队必须与故事点的估计更准确
如果团队不知道他们的速度准确;然后冲刺可能早期结束或最近

嗨,小问题。

我新scrum和寻找方法来提高我们公司的理解。我只是想知道任何人都可以澄清几点。

• 如果PBI不会完成sprint快结束的时候,我就在说我们允许sprint结束,此举PBI到下一个sprint(这应该仍然优先)
• 如果阿宝& SM不可用冲刺评审和复古由于训练,这个事件应该搬到周一说,或允许开发人员仍然持有他们选择记录吗?另一个选择可能延长冲刺了一周的长度吗?

对不起如果这些看似简单的问题,但我坚持要坚持scrum框架和事件之间试图确保我们得到价值的回顾与怀旧。

谢谢提前

韦恩

• 如果PBI不会完成sprint快结束的时候,我就在说我们允许sprint结束

Sprint结束时到期后的成果。这不是在你的能力范围内允许或不允许。

• 此举PBI到下一个sprint(这应该仍然优先)

产品待办事项列表应该给在工作透明度,据信仍为产品。开发人员应该重新评估任何未完成相应工作。产品所有者可能会,也可能不会,然后顺序优先考虑下一个Sprint规划活动的问题。

• 如果阿宝& SM不可用冲刺评审和复古由于训练,这个事件应该搬到周一说,或允许开发人员仍然持有他们选择记录吗?另一个选择可能延长冲刺了一周的长度吗?

在Sprint结束时,钟说。你甚至不能扩展它如果你想。如果它是可能的,透明度和问责制将会降低。团队需要看到和了解他们有问题,在这种情况下做出最好的决定。

当没有发生什么物品积压。这意味着浮渣积压成功没有项目吗?

当没有发生什么物品积压。这意味着浮渣积压成功没有项目吗?

空积压表明,不再有任何值得做的工作。我不一定会把这等同于成功。

Scrum的指南

产品待办事项列表是一个渐进的、有序列表需要改进的产品。它是单一的来源由Scrum团队工作。

如果产品待办事项列表是空的,这就表示对我来说,你的组织被称为“摇钱树”。如果人们仍然使用该产品但是你不投资钱在维护,这是一件好事。如果产品待办事项列表是空的,因为组织已经决定不值得投资的产品,也可以是一件好事。但它也可以是一件坏事。

我,喜欢@Ian,很难把一个空的产品待办事项列表等同于成功。如果你是指一个Sprint Backlog,我会有相似的看法,发现很难等同于成功。空积压只是说,没有更多的工作要做的上下文中积压的目的。

我知道你有一个错误在你的问题,但我真的认为我可以使用这句话在将来的某个时候。“待办事项列表是空的,看起来像人渣已经成功”。:-)

博士tl;当你的团队修复功能没有开发正常吗?

假设开发人员有相当大的任务和公关的接近sprint结束。然后在评审或测试期间,原来这不是能正确实施和开发需要修复它之前能够释放它。sprint是完成。在这种情况下,你做什么?你把这当作积压的未完成的项目吗?

然后在评审或测试期间,原来这不是能正确实施和开发需要修复它之前能够释放它。

在这种情况下,你说待定项不满足“完成”的定义,所以项目返回产品待办事项列表应该换换脑子。如果它仍然是有价值的去做应该返回sprint backlog的下一个sprint计划会议。

不属于沉没成本谬误。就因为我们已经做了一些工作,这并不意味着我们必须完成它。问题仍然是一如既往地“接下来工作的最有价值的东西是什么?”,所有产品所有权和开发责任的一般规则仍然适用。