使用看板进行Sprint计划
“当试图教一个人什么是边界时，他们从边界的执行中学到的较少，更多的是从边界建立的方式中学到的。”——布莱恩特·h·麦吉尔
几个月前我们看到团队如何优化跨越Sprint边界的流程，这是一种基于他们做出有限和可持续承诺的能力的技术。
总结一下:团队计划的Sprint Backlog中并不是所有的工作都必须与Sprint目标以及团队成员对该目标的承诺相关。例如，他们可能只将60%的能力分配给“必须拥有”的项目，这些项目对于Sprint目标的实现至关重要。剩下的40%可能会被分为“本该”和“本来可以”，前者会优化目标结果，但对目标并不重要，后者虽然有价值，但可能与目标完全无关。这使得团队能够将协商的范围作为缓冲，从而可以处理不可预见的问题。换句话说，如果任何需求必须在范围之外进行“交易”——也许是因为团队必须加快计划外和紧急的工作，例如缺陷或中断——那么高达40%的Sprint Backlog容量可以重新协商以促进安排。Sprint目标，只需要60%的团队能力，可能仍然是可以实现的，没有团队成员会被期望为了实现它而工作很长时间。
我们还看到，团队可以使用蒙特卡罗分析来确定Sprint Backlog容量中真正应该明确表达到联合承诺(如Sprint目标)的比例。当然，将容量限制在60%以内不过是行业中经常应用的经验法则，尤其是那些接触过DSDM的人。我们研究了当这个百分比被认为是次优时，团队如何使用实际历史数据进行模拟，以得出更好的数字。
这不仅为团队提供了定义承诺的方法，他们可以合理地对Sprint Backlog上的工作做出承诺，而且还提供了一种方法来优化跨越Sprint边界的流程。如果Sprint目标及时实现，那么backlog上的任何剩余工作都将是非关键的。在时间框的剩余时间内，一个不可预见的事件仍然可能发生，但是它不能将已经满足发布质量的已完成定义，并满足Sprint目标的增量置于危险之中。因此，在Sprint的其余部分中进行的任何工作都不意味着承诺的升级。这项工作可能完成，也可能没有完成，它可以重新谈判，以利用其他机会。可能会被修改即时这样开发团队就可以尽可能无缝地进入下一个Sprint。Sprint目标的实现可以有效地成为重新规划的触发器。例如，团队可以与产品负责人协商，并开始处理产品待办事项列表顶部的那些项目，使用细化作为输入。只要团队成员已经完成了他们的Sprint承诺，就不需要期望这项工作将在当前Sprint结束之前完成。
重要的是要意识到，一旦Sprint时间框结束，未完成的工作不会简单地“滚动”到下一个。相反，它是在产品待办事项列表上重新估计的，以表明还剩下多少。同样需要注意的是，无论新开始的工作在接下来的Sprint中继续进行的可能性有多大，都不能保证会发生这种情况，产品负责人可以在任何时候自由地重新调整产品待办事项列表的优先级。理论上，团队可以在一两天后进入Sprint计划，并在证据中发现完全不同的优先级集合。他们开始未完成的工作可能会在之后的Sprint中重新开始……或者根本就不做。任何提前开始的工作，如果没有完成，就会导致折旧、任务转换和其他形式的浪费。因此，它一开始就有风险。然而，如果产品待办事项列表的细化做得很好，它没有被计划到下一个Sprint的可能性将会降到最低，并且流程的优化将被证明是可实现的和值得的。
现在，如果一个Sprint边界在流经它的工作方面变得很大程度上是无缝的，某些工作在一个时间框中开始，只是在下一个时间框中完成，那么就会对Sprint计划应该如何进行产生影响。的Scrum团队的看板指南没有提到边界的跨越，但仍然将焦点直接放在流上，指出“基于流的Sprint计划会议使用流度量作为开发Sprint Backlog的辅助”。从蒙特卡罗分析获得的吞吐量数据可能是一个考虑因素。其他包括周期时间和项目在完成前所花费的时间。例如，如果要实现其服务水平期望，那么已经开始的项目很可能必须计划完成。
健康的流程需求将指导和塑造基于看板的Sprint计划会议中预测的工作。每个Sprint目标都将根据一个滚动的工作流程来构建，并提出新的可能性。Sprint目标所代表的功能一致性可能不一定在特定的工作选择中找到，而是在看板指南所描述的流度量中找到。一个团队可能合理地决定他们这次Sprint的目标是提高吞吐量，或者减少周期时间，或者可能消除工作项年龄中的任何威胁给定服务水平的异常值。换句话说，基于流程的Sprint目标可能是Scrum团队必须提交的任务，以及需要他们协作和专注的功能结果。
对于许多Scrum老手来说，这种偏离面向功能的Sprint目标的转变可能看起来太像看板了，而且不和谐。但是请记住，在这个方案中仍然存在一个连贯的Sprint目标，以及与之相关的Sprint。这是Scrum的核心，尽管它是一种看板策略。两者都只是最低限度地规定了团队应该做什么。我们面临的挑战是，如果实现要成功，就必须期望团队成员相互之间有更高水平的理解和成就。
一旦根据基于流程的计划来考虑和重新评估补充Sprint Backlog的实际触发因素，热度就会进一步上升。越加快流程，Sprint边界对工作的检查和调整就越不重要。团队将有机会以更及时的方式利用经验控制，可能是在持续交付的基础上。Sprint Backlog的补充应该反映这些条件，而不需要仅仅局限于一个Sprint计划事件，其核心目的是同意并承诺一个不变的Sprint目标。换句话说，在Scrum中一直被认为是突发事件的Sprint Backlog，可以在看板工作流策略决定的附加点上得到补充。
我们已经考虑了一个这样的策略——当Sprint目标得到满足时，任何留在Sprint Backlog中的非关键工作都应该重新计划。如果产品待办事项细化表明不同的项目可能在下一个Sprint计划会议中被采用，那么非关键的工作可以被交换出去，而潜在的更重要的工作被协商进来。因此，团队可以更及时地开始处理这些项目，并促进Sprint边界之间不间断的流动。
当Scrum团队在跨迭代的积极管理工作中获得信心时，可以考虑一种可能更好地优化流程的替代策略。Sprint Backlog补充可以在内容被耗尽到某个级别时执行，这是一个与Sprint边界和Sprint目标的实现分离的触发器。对于Sprint目标本身变得更加基于流程的团队来说，这可能是一个合乎逻辑的进展，并且优先级的表达正在从“必须有”、“应该有”和“可能有”的需求转移到建立服务水平期望。Sprint边界现在开始表示一个有规律的心跳，此时面向流的目标得到了同意和验证。
基于流程的Sprint计划并不适用于每个团队。Scrum是为复杂产品的开发和交付而设计的，而构建和满足特性驱动的Sprint目标已被证明是经验控制相关风险的好方法。然而，复杂积域不是一个二元状态，而是一个介于混沌环境和复杂环境之间的连续体。一般来说，随着产品的成熟，不确定性会随着所面临风险的大小而逐渐减少。复杂的产品开始变得“仅仅”复杂，标准化的模板化变更可以逐渐成为规范。这促成了一种模式——在整个行业广泛存在——在新产品开发工作中使用Scrum，而在“正常业务”中切换到看板。
这种模式提供了一个非常简单的描述，说明何时特性驱动的开发可能让位于流程的优化。然而在实践中，复杂性并不是以线性方式降低的。一个产品从复杂到复杂的进化之旅是坎坷不平的。过早地从Scrum切换到看板的团队仍然会面临挑战，这些挑战可以通过面向功能的目标得到最好的缓解，尽管频率可能会降低。这就是为什么Scrum团队掌握基于流程的计划是很有用的。看板是一种他们可以根据需要使用的策略，它不需要他们在使用Scrum框架本身上妥协。