不要在Sprint计划中评估故事
这是一系列估计的第三部分。第一部分是“不要估计软件缺陷第二部分是“不要估计尖刺”。第三部分是关于评估故事。
我不太喜欢在sprint计划中评估故事。我不会这样做，也不会在sprint计划中重新评估故事。我在单独的评估会议上评估故事，通常至少提前几个sprint，如果不是更多的话。有一些原因(重新)估算故事在sprint计划是一个危险的做法:在sprint计划,我们正在考虑在一个较低的水平的细节和更了解这个故事,代码库和系统比我们当我们估计剩下的积压。您不能在sprint计划中正确地评估这样一个故事，而不是像其他一些描述那样详细地评估。这样的做法导致了速度膨胀和冒险的发行计划。
不同的细节水平
一旦我们开始冲刺计划，我们可能已经实施了与故事相关的尖峰，我们正在挖掘故事细节。我们已经考虑了对故事的代码的设计。我们正在挖掘任务。当我们估计其余的积压时，我们对这个故事的更多信息更多。
所以，如果我估计或重新获得Sprint计划中的故事，我不能相对估计其余的积压。我不知道关于其他故事的细节水平。我现在正在考虑不同的细节，使用不同的思维，而不是估计其他故事。
我们知道我们的估计是错误的。当我们在发布计划中进行评估时，我们知道它们是错误的，当我们开始sprint计划时，我们知道它们仍然是错误的。这就是为什么我们有速度——一种把所有错误都考虑进去的经验测量。
在Sprint计划期间，我们将故事分解为任务，估计这些任务，并比较任务估算抵御我们的能力。这是不是要点，让我们免于在这个冲刺中过度使用。无需改变估计。
“所以呢？”你问。忍受我，我会告诉你为什么要关心。
更多的知识和技能
如果您正在发布承诺，如果您有释放计划，或者如果您遵循我们的其他建议，然后您的释放积压可能很多几周前估计。所有这些估计都没有利益我们现在所知道的。其中许多估计是可疑的。可能是错误的。如果我们允许估计更改，一旦我们击中Sprint计划，就会有更估算Sprint规划的变化。这不是唯一的错误估计。如果这往往发生过经常（发现差别差），我们应该重新考虑深吸岭的培养程度以及我们是否应该重新度过整个剩余时间产品积压。
“那么？”，你问“我只是喜欢我的估计是正确的。”考虑如何在Sprint计划中重新定位可能会影响我们的速度，因此释放计划......
通货膨胀的速度
新的估计很可能会更高，而不是更低。如果估计太大，就不考虑开发。他们可能不会提这件事。如果估算过小，开发就会非常关注。
想想您在Sprint规划中更改或想要更改估算的频率。持续这个数字一会儿。也许是每隔一个冲刺的一个故事？也许更多？也许是20分？还要考虑通常的增加程度。它是3到5个吗？从1到2？从5到8？也许这通常是1.6倍的增加？
想想产品积压的其余部分。如果我们在最后一分钟倾向于增加5％的故事1.6倍，那么你的速度相对于你的剩余产品积压太大。剩余的积压是相对于原始点估计的，而不相对于被重新定位点。
这是一个例子
例子:假设我们通常在大约10个故事和每小时20点，并且尺寸的分布是[1,1,1,2,2,2,3,3,5]的分布。假设这是一个3点故事，成为一个5.如果我们完成所有这些故事，我们应该说我们的速度为20或22吗？假设我们的释放积压中有400分。我们可以在每个Sprint中释放第二个反冲中实现22分吗？我会说不，你只能淘汰20个冲刺的20个积分点。
要查看另一种方式，您认为您的积压中有400分，但由于您将在飞行中重新获得它们，因此您真的有440分。您将在400/22迭代中完成。您将在440/22迭代中完成。或400/20。
我们的团队生产其能力，其能力，稳定或至少不迅速增加。这是我们的现金。然而，由于通货膨胀，故事的价格可以更快地增加。Silly Violmy：我想买一个最初售价400美元的积压。我无法立即为此付出代价，所以我开始抛开每个支付期的钱。我可以向这个积压缩短22美元，但随着我的原来的400美元的时间，我发现这家商店将价格升至440美元。bummer。
结论
如果我正在发出释放承诺，我希望绝对肯定我不会过度使用。我想在提交和交付。我将评估风险，提前降低风险，在我的积压（创建选项）中放风险缓解故事，并为这些风险保留缓冲区，而不是缓解。我会期待我不知道我们需要做的所有故事。我们没有想到我们将要处理的一些暗物质，所以我为此保留了一点缓冲区。这是一种合理和谨慎的方法。我绝对不希望速度通胀消耗那些小的缓冲区。我需要他们，因为我把它们放在一边。如果我允许速度通胀来利用我的偶然性，那么我正在运行一个比我想象的风险渊博的项目。
出于类似的原因，我不会估计新发现的缺陷或计划生育的尖峰。如果您不小心，您将涌入速度，并估计剩余积压的大小。
评论（8）
乔治·迪维迪
更普遍的说法是，不要在开始工作之后重新评估，因为您获得了在开始之前评估时无法知道的知识，因此这些评估不再与开始之前的评估具有可比性。最糟糕的情况是，人们想在事后修改估计。“这个故事比我们想象的要难得多，所以我们应该得到8分，而不是3分。”
使用此更广泛的版本使其适用于与您描述的工作流程不同的工作。例如，在Sprint规划期间，我发现相对较少的团队在Sprint规划期间进行任务细分，在故事上工作时选择JIT任务细分。这种方式工作的团队不再做任务估计，因为它不再提供价值，并且仅仅需要时间和精力。通常，如果它们遇到足够大的任务似乎有助于帮助，它们通常会将故事较小。使用小故事而不是任务故障，需要在团队中更多的合作，但也鼓励限制在工作中的工作软件上的过程和专注。
此外，它并不总是适合“在提交和交付”中。在很多企业环境中，这是最安全，最简单的方式出现能力。在其他环境中，该组织的风险越来越少，并且会因推动越来越多地实现更多的，以管理不确定性越早。
这方面的概括是我们估计的原因是预测当给定金额数量的工作或者在给定的时间箱中有多少工作。如果我们记得我们想要用估算回答的问题，很容易看出我们以后不想改变我们的估计值。至少，我们不想以例行改变它们;可能有例外，我们宁愿做别的事情。
当我们忘记我们试图回答的问题时，很容易将估计视为“竞争团队的信用”或“生产力衡量标准”。这些引导我们对不加强工作软件生产的行为模式。
谢谢，乔治！我喜欢这种泛化。这是有帮助的，是一种更好的方式来词。
Iakiv
嗨,安德鲁!
我有一些问题：）
当我第一次熟悉帖子中的想法时（从JIRA官方文件顺便说），我非常喜欢他们。
但我仍然没有设法把它们放进生活中。
我们的团队在6岁时开始该项目。系统非常复杂，大...而且 - 在前端也很笨重。
当我试图在不知道详情时才能提供估计时，我遇到了以下事情让我感到困惑我：
1.由于庞大的前端，缺乏UI / UX设计师涉及，缺乏PO资源，可能发生意外的优先事项 - 通常是前端开发人员估计这样：如果我们走到最简单的方式，那亚傅体育app么它将是3，如果更多“聪明” -5，如果“最聪明” - 8。
2.由于旧的和复杂的项目，因为我们是IT中的新团队 - 后端可以估计这样：100个SP，Infinity或3 SP如果它恰好实现很容易，否则......即使故事也是如此听起来像“用户透视的很小变化”。
这就是为什么我们经常等待在“1”案件中更加澄清，并等待在“2”案件中的开发人员至少一些调查，以便提供“初始”估计。我们不会在...之后改变它
你对此有什么看法?在我们的情况下，有没有办法不“等待”?
我很想找一个……
谢谢
嗨Iakiv
“因为庞大的前端，缺少ui/ux设计师的参与，缺乏PO资源，…我们经常等待更多关于PO的澄清…”亚傅体育app
我猜你正在努力解决这个问题。你必须有一个很好的阿宝和阿宝团队(http://leadingagile.wpengine.com/2011/03/why-a-product-owner-team/)并有很好的积压(http://leadingagile.wpengine.com/2014/02/Managing-Risk-uncTerainty-agile-2/）。
>“由于旧和复杂的项目，因为我们是它的新团队 - 后端人可能会估计这样......这就是为什么我们经常......等待开发人员至少一些调查......你有关于这个的想法吗？有没有办法在我们的案件中“等待”吗？“
这就是为什么我们有尖峰以及为什么我们早期识别和实施尖刺，因为我通常合作的组织类型，这是那些需要协调多个团队的工作并需要一些可预测性的组织。如果您的上下文不同，我的建议可能不适用于您。在我的上下文中，我有一个技术合作与宝宝进行培训这些故事，识别尖峰，帮助估计，并回答复杂性问题。PO团队需要了解它的换乘和新郎2,3或提前更多的冲刺，具体取决于情况。
在正确的角色中没有替代合适的人在做需要完成的工作。
托马斯苏伯拉
嗨安德鲁，
如果我和你在一起，我并不完全肯定。如果它只是增加1.6倍的增加，我并不真正关心，团队也是如此。
但是，如果故事在第一个冲刺计划阶段内的1比5中迅速增加，那么怎么办。我同意有关一个故事的最多信息尚不清楚，但这就是为什么我们总是在第一次估计之前谈论每个新故事，所以一切都应该清楚球队。
但有时它发生了，它没有任何错误。宝宝只是以为它清楚地表明了一个需要的东西b和c，另一方的团队感到被欺骗，因为关于故事的重要信息丢失了。这只是一个特征，但很好......我真的需要这件事也需要这件事。（复杂性成本* Bing *）..并且在这个情况下，PO没有错。仍然有一个故事..但比团队的想法更复杂。（并不能将故事切成较小的故事）
现在你说，如果故事是事后评估的，它将改变它的行为。是的，应该是这样。因为在这个sprint中，团队的速度不是20，而是16，这会让每个人都怀疑是否出了什么问题。
我必须承认这不是每天的基础问题，一年中的一个或两个，但较近我会向你提出意见。
提前致谢
托马斯。谢谢你参与这一点。
在我到达你的问题的核心之前，让我发表评论你的第一句话。我在帖子中使用的数字只是例子，我试图让他们保守。任何给定的团队的实际数字肯定会更糟糕。但是，随着这些数字坚持下来，这些数字努力使得在面对这种情况下承诺的人将在释放持续时间的10％，如果我的号码是保守的，那么如果我的数字是保守的。+/- 10％通常是可以接受的，但如果你无意中计划进入10％的延迟标记，你最终可能会更糟。对于不可预见的事情，您需要+/- 10％（例如您评论的正文中的示例），而不是可预防的数学错误。
现在，我会解决你的真实问题：在你的例子中，存在误解，一种误解。它发生了。这是我们不在同一页面的地方，随着你的评论“因为，而不是20个团队只能在这个冲刺中生成16个，这将使每个人都知道错误的错误。”你不希望任何人提问或思考什么是错误的。我想我们应该让每个人都想知道有什么问题。让我们讨论回顾性并改善我们的过程。让我们减少这种类型的未来发生。不要说一切都好。不要改变数字，以便没有人会提出问题。
祝你好运!
安德鲁
杰夫
你好
但如果10%的缓冲不够，如何及时满足这一需求缺口呢?我们建议po将其添加为下一个sprint的任务。
宝经常拒绝这一点
嗨杰夫。我不确定您是否正在写入Sprint或更大的东西，例如释放计划或季度规划周期。对于单个/罕见的冲刺，我并不担心在冲刺级别的小额过度使用。如果它不经常发生，我应该在更大的计划中有足够的储备来吸收一个冲刺的懒人。
任何时候在一个组织中有人意识到他们过度投入了一些更大的事情，比如季度计划周期，他们应该就如何解决这个问题进行讨论。我建议最好的办法是缩小一些范围。他们可以重新协商日期，但延长日期并不是真正的小批量，快速反馈，MVP，或灵活性的精神。他们可以要求加班，但这通常不好，因为这会破坏安全、士气和质量。他们可以增加人员，但这通常会导致项目推迟，并没有保持团队在一起(稳定)的精神，这是我推荐的另一种做法。
为什么你的宝拒绝将未完成的任务添加到下一个Sprint？我会拒绝将未完成的任务添加到下一个Sprint，而不会拖动未完成的故事以及任务，或者没有分裂故事。我认为宝宝仍然想要那些任务。如果是这样，他有什么选择？