以下内容来自：https://www.humanizingwork.com/the-humanizing-work-guide-to-splitting-user-stories/#flowchart，只为个人学习与分享使用。
Humanizing Work是一家从事敏捷培训的公司，由三位资深敏捷教练创立。Richard Lawrence、Peter Green、Angie Ham。
全文为chrome一键翻译的，将就能看懂。
分割用户故事的人性化工作指南
正如《敏捷宣言》的作者所说：“我们正在发现更好的方法……通过这样做并帮助其他人来做。” 至少从2005年开始，我们就一直在进行有关用户故事拆分的实践，写作和指导。理查德的故事拆分流程图已被下载数十万次。与客户单独合作，我们发现在此领域中非常有效的模式。现在，当我们一起组建人性化工作公司时，我们已经合并和更新了所有将故事内容分解为新指南的内容。这包括我们在过去十年中发现的一些“更好的方法”，其中有一半是在指导客户将他们的积压项目分配到各种各样的环境中的。
内容
为什么讲故事很重要
什么是一个好的用户故事？
用户故事格式
投资良好的用户故事
用户故事是垂直切分
故事分解流程图
步骤1：准备输入故事（或功能）
步骤2：套用样式
步骤3：评估分割
Cynefin和故事分裂
善于故事分解
垂直切片和比例
您是否应该有100多个人员在开发单个产品？
垂直切片的底线刻度
下一步
为什么讲故事很重要
通过优先处理小型用户故事的积压工作，团队可以频繁获取价值和高质量的反馈。许多团队努力将大型用户故事和功能分解为好的小型故事。他们没有在整个体系结构中获得小的垂直切面，而是获得了看起来更像任务或体系结构组件的故事，而没有体验到小故事应提供的价值或反馈。
幸运的是，故事拆分是一种可以在较短时间内学会的技能。我们已经看到团队仅需几个小时的练习和一些简单的工具就可以从挣扎中解脱出来，流利地讲故事。稍后，我们将研究如何组织该练习。
什么使一个好的用户故事？
在讨论拆分用户故事之前，我们需要确保我们对什么是好故事以及什么样的事情可以和不能拆分成好故事有共同的理解。
首先，一个定义：用户故事只是从用户的角度描述系统行为的变化。它描述了用户想要对系统执行的操作或希望系统为他们执行的操作，而今天这些功能并没有执行。
顺便说一下，请注意，这位于解决方案空间而不是问题空间。这并不是要在某个地方完成某项任务的人的描述，例如待完成的工作（JTBD）。这是对想要在系统中完成某事的人的描述。JTBD非常适合问题空间中的客户同理。用户故事非常适合将客户的共鸣转化为对软件系统的一系列更改，同时始终保持用户的观点。
用户故事格式
您经常会看到以特定格式编写的用户故事：
作为角色，
我需要采取行动或发挥作用，
以便获得价值或目标
有时
为了价值或目标
作为角色，
我想要采取行动或发挥作用
该模板的优点在于可以回答用户故事中的三个问题：
是给谁用的？
他们想做什么？或者让系统做什么？这是今天无法实现的？
他们为什么要这个？
不过，重要的不是模板。它正在回答三个问题。
实际上，我们很少会使用完整的模板来编写故事。无论是在便利贴的顶部还是在数字工具的标题字段中，简短标题都是有用的。标题通常用作“内容”。“谁”通常由描述核心目标客户的产品或发布愿景提供。如果故事是针对目标客户的，我们将不再重复。该客户在我们的故事卡中充当默认用户，因此我们只会发出例外情况。最后，我们将确保在工具的说明字段中或在便利贴上用较浅的字体说明了原因。
因此，如果我们在公共图书馆网站上工作，而图书馆主是我们的默认用户，
作为图书馆的赞助人，
我想按书名搜索一本书，
以便在搜索结果中毫无干扰地找到我想要的书
我们会写
按确切标题查找，
因为我知道我想要的特定书籍，并且希望避免在搜索结果中出现干扰
有时，我们会遇到一些假装是故事的任务或组件。即使您使用诸如“作为开发人员，我想要一个数据库图，这样我就知道数据库的结构将是什么”之类的神奇词汇，这仍然是一项任务。
投资良好的用户故事
几年前，极限编程的先驱Bill Wake提出了一个很好的首字母缩略词，表示一个良好的用户故事的6个关键属性：INVEST。让我们看看它们中的每一个。
I代表INDEPENDENT。这意味着一个好的故事是完全独立的，可以通过除技术依赖之外的其他事物来优先处理。有时，这意味着临时搭建一些脚手架，以便可以独立测试故事，从而使您可以尽早进行操作以在项目早期获得价值或降低风险。
N是可转让的。一个好的故事为围绕什么以及如何进行细节的协作留有余地。当然，随着协作的进行和您捕获更多细节，故事变得不再那么容易商量了。
V是VALUABLE。每个故事都应为用户增加一定程度的可见价值。目前看来，这似乎是不可能的。您可能积压成堆的组件和基础结构任务，而这些任务和基础结构任务伪装成故事，并没有为用户增加价值。但是，当您开发故事分解技能时，您会更好地找到可以带来直接价值的功能薄片。
（故事并不需要自己提供足够的价值来值得运送。您可能需要积累一些故事，才能从有价值的故事转变为可交易的故事。我们喜欢最小可交易功能或MMF作为故事的容器。）
E是ESTIMABLE的意思。一个好的故事的定义足够使团队可以估计它的大小，通常相对于待办事项中的其他故事而言。
S是SMALL。我们的经验法则是足够小，当一个故事到达您的待办事项列表的顶部时，您应该能够将6到10放入冲刺中。这是关于获得频繁的反馈和管理风险而无需管理太多故事。这是一个比率，因此可以随着冲刺长度，团队规模和速度等因素进行缩放。
最后T是TESTABLE。我们应该有某种方式知道我们已经完成了这个故事。这不仅是一个模糊的愿望，而且需要是系统行为的具体变化。
当然，其中一些属性之间存在紧张关系。例如，随着故事的规模变小，使其变得独立且有价值的难度越来越大。它们越是可协商的，它们就越难以估计和检验。
幸运的是，不同的属性在不同的时间起作用。在进行冲刺计划时，更重要的是故事要小，可估计和可测试。我们仍然需要一些独立性，可谈判性和价值，但是这些属性变得不那么重要了。在未来，情况恰恰相反。
用户故事是垂直切分
您经常会听到有关好故事的术语“垂直切片”。这是关于相对于软件体系结构的好故事的形式。
垂直切片是“工作项的缩写，它可以对系统行为进行重要的更改，因此您可能必须接触多个体系结构层才能实现更改。” 当您将切片称为“完成”时，该系统对于用户而言显然更有价值。
这与水平切片相反，水平切片是指代表对一个组件或体系结构层的更改的工作项，该工作项需要与对其他组件或体系结构的更改进行组合才能对用户具有可观察的价值。
让我们看一个非常简单的架构。有一个UI层，一些业务逻辑和一个数据库。您的系统可能比这更复杂，但是它可能至少包含这三层。
要获得大多数INVEST属性，故事必定会涉及所有3个建筑层。如果不进行某些UI更改，某些逻辑更改和某些持久性更改，我们可能将无法交付价值。因此，故事是整个系统的垂直切面。
有时，这些垂直切片非常宽。当我们进行故事拆分时，我们将讨论如何在较宽的垂直切片中找到垂直的垂直切片，但到目前为止，足以知道故事应跨层建筑层以创造价值就足够了。
许多新的敏捷团队尝试按体系结构层划分故事：一个故事用于UI，另一个故事用于数据库，等等。虽然这个故事可能很小，但由于独立且有价值而失败。
当团队按垂直方向工作时，他们
在他们的积压中使价值明确
有更多关于价值的对话
倾向于不要意外地建立低价值的变化
早日获得价值
获得更早，更高质量的反馈
更轻松地查看约束和清单，并可以做出相应的响应
在交付价值时变得更加可预测（因为工作软件成为进度的主要衡量标准）
我们可以继续，但这给您带来了主意。当我们坐在一起，绘制出成功的敏捷团队中看到的各种习惯以及它们之间的相互关系时，我们发现在垂直的层面上工作可以使或至少与几乎所有其他习惯相关。
查看您的产品积压订单中的故事，其中一些是您最近完成的，有些是将来的。根据投资标准评估每个人。看看您是否可以找到垂直切面的故事，而找不到垂直切面的故事。然后，看看是否可以改善您的故事。
故事分解流程图
为了支持我们指导的团队，Richard创建了一个故事分解流程图，该流程图处理了当我们在帮助团队分解故事时会提出的问题。（单击下面的图像下载流程图的PDF。）
得益于来自全球敏捷社区的志愿者，流程图已被翻译成多种语言。以下是当前所有当前版本：英语–如何拆分用户故事
西班牙语–科莫Dividir una Historia de Usuario
法语–评论DécouperunRécitUtilisateur
葡萄牙语–科莫Dividir umaHistóriadeUsuário
德语–用户案例Aufteilen
匈牙利语– Hogyan daraboljuk用户案例-kat
俄语–КакРазделятьИсторииПользователей
中文–用户故事切分招数
有兴趣翻译成您的语言吗？这是我们处理新翻译的方法。
让我们看一下图表的三个部分。
步骤1：准备输入故事（或功能）
首先，请确保您要拆分的故事（或故事）满足INVEST标准（不包括小故事）。通常，贵重是问题所在。当人们给我们带来他们“无法分裂”的故事时，它们原来就是伪装成故事的任务或组成部分。如果您从不增加价值的东西入手，就无法将其切成较小的值并获得价值的增加。在这种情况下，下一步是将非故事与其他作品组合在一起，以便它们一起代表价值的增长。
接下来，切片太大了吗？如果是的话，是时候将其拆分了。
步骤2：套用样式
模式1：工作流程步骤
这是我们的一个客户正在创建的内容管理系统中的一个故事：
作为内容管理员，我可以将新闻故事发布到公司网站。
听起来并不算太大-直到我们深入研究工作流程以发表故事为止。事实证明，要在公司网站上获得几句话新闻报道，就需要编辑和法律批准以及在登台网站上进行最终审查。像这样的6到10个故事都不可能一次迭代。
在这样的工作流程中，最大的价值通常来自开始和结束。中间步骤可增加增量价值，但并不孤单。因此，首先构建简单的端到端案例，然后添加中间步骤和特殊案例，可以很好地发挥作用。
新的故事包括：
…我可以直接将新闻报道发布到公司网站上。
…我可以发布新闻报道，并提供编辑评论。
…我可以发布具有法律评论的新闻报道。
…我可以在临时站点上查看新闻报道。
…我可以在登台现场发布新闻报道。
但是有时候，整个工作流程很重要，因此您不能仅从头开始和结束。在这种情况下，请在整个工作流程中寻找一个薄薄的环节。也许它支持最常见的情况。也许您对工作流程中最易理解的部分进行了硬编码或简化，以便您可以探索更复杂的部分。
无论哪种方式，最明显的分裂（从头到尾每次都迈出一步）是错误的方法。
模式2：操作（例如CRUD）
用户故事中的“管理”一词是一个礼物，它涵盖了多个操作。这提供了一种自然的方式来分解故事。例如：
作为用户，我可以管理我的帐户。
变成
…我可以注册一个帐户。
…我可以编辑我的帐户设置。
…我可以取消我的帐户。
模式3：业务规则变化
这个故事中隐藏着一些同样复杂的故事，这些故事可以使用不同的业务规则来完成相同的任务：
作为用户，我可以搜索日期灵活的航班。
深入研究“灵活的日期”会发现几种不同的业务规则，每条规则本身都是一个好故事：
…为“ x和y之间的n天”。
…作为“十二月的一个周末”。
…为“ x和y的±n天”。
模式4：数据变化
故事中的复杂性可能来自处理数据的变化。例如，我们当前正在处理的系统需要对运输提供商所服务的地理区域进行建模。我们本来可以处理整个地理区域的预算就花光了；这可能很复杂。当我们讲故事时，
作为用户，我可以按旅行起点和目的地搜索运输提供商。
与我们的产品负责人一起，我们发现，虽然我们不需要完整的GIS，但是地理建模仍然非常复杂。我们停下脚步，问：“建模地理的'足够好'的方法是什么，以便我们现在可以构建其他高价值要素？” 我们安顿下来，
作为用户，我可以按旅行始发地和目的地（县）搜索运输提供商。
这工作了一段时间，直到我们收集了更多数据并发现某些提供商仅为某些城市甚至邻里提供服务。于是出现了一个新故事：
作为用户，我可以按旅行起点和目的地（县，城市，镇或街区）搜索运输提供商。
查看新的提供商数据，我们还发现一些提供商将支持源自单个城市但结束于任何数量的周围城市的旅行。这导致了故事：
提供商可以为旅行的出发地和目的地提供不同的地理区域。
这三个故事均与原始地理故事分开。此处的区别在于，我们在构建最简单的版本后及时添加了故事。
但有时您会预先了解数据差异。经典示例是本地化：
作为内容管理员，我可以创建新闻故事。
…用英语讲。
……日语。
……阿拉伯语。
…等等。
模式5：数据输入方法
有时，复杂性在于用户界面中，而不是功能本身中。在这种情况下，请分割故事以使用最简单的UI进行构建，然后构建更可用或更高级的UI。当然，这些不是独立的-如果您先做第二个故事，则实际上是原始故事-但它仍然是有用的拆分。
作为用户，我可以搜索两个目的地之间的航班。
可以分为
…使用简单的日期输入。
…带有精美的日历界面。
模式6：大努力
有时，一个故事可以分为几个部分，其中大部分工作将用于实施第一个故事。例如，这个信用卡处理的故事，
作为用户，我可以使用VISA，MasterCard，Diners Club或American Express支付机票费用。
可以分为四个故事，每种卡片类型一个。但是将建立信用卡处理基础设施来支持第一个故事。添加更多的卡类型相对来说是微不足道的。我们可以估计第一个故事要比其他三个故事大，但是如果产品负责人后来更改优先级，我们就必须记住要更改我们的估计。相反，我们应该像这样首先推迟关于哪种卡类型首先实现的决定：
…我可以使用一种信用卡类型（VISA，MC，DC，AMEX）付款。
…我可以使用所有四种信用卡类型（VISA，MC，DC，AMEX）付款（前提是已经实施了一种信用卡类型）。
这两个新故事仍然不是独立的，但是与每种卡片类型的故事相比，其依赖性要明显得多。
模式7：简单/复杂
当您在计划会议上讨论一个故事时，这个故事似乎越来越大（“ x到底是什么？”；“您是否考虑过y？”），停下来问：“最简单的版本是什么？ ？” 将该简单版本捕获为自己的故事。您可能必须在现场定义一些验收标准，以使其变得简单。然后，将所有变化和复杂性分解为各自的故事。例如，这个故事
作为用户，我可以搜索两个目的地之间的航班。
通过拆分各种变体来保持简单，
…指定最大停靠点数。
…包括附近的机场。
…使用灵活的日期。
…等等。
这种模式实际上是关于寻找故事的核心并使之保持简单。将每个变体移动到自己的故事中。
模式8：延缓性能
有时，很大一部分工作是使功能快速完成-最初的实现并不那么困难。但是您可以从缓慢的实施中学到很多东西，并且它对于无法以故事形式进行操作的用户具有一定的价值。在这种情况下，将故事分为“使之起作用”和“使其快速”：
作为用户，我可以搜索两个目的地之间的航班。
…（慢-完成它，显示一个“搜索”动画）。
…（不到5秒）。
这种方法可以满足任何非功能性需求，而不仅仅是性能。您可以使其工作，然后使其安全。使它工作，然后使其缩放。等等。
不过要小心。养成习惯是将尚未完成的故事称为未完成的故事，积later以后需要偿还的债务。
模式9：突刺
一个故事可能不是很大，不是因为它一定很复杂，而是因为对其实现了解甚少。在这种情况下，谈论故事的业务部分不会使您分手。首先执行时间限制，以解决实施过程中的不确定性。然后，您可以执行实现或更好地了解如何对其进行分解。不知道如何实施以下故事？
作为用户，我可以用信用卡付款。
然后，将其分解为：
调查信用卡处理。
实施信用卡处理。
在“调查”故事中，接受标准应该是您需要回答的问题。做足够的调查以回答问题并停止；很容易发疯进行研究。
尖峰拆分是最后的选择，因为它应该是您的最后选择。您可能知道足够的知识来构建某些东西。这样做，您将了解更多。因此，在采用尖峰模式之前，请尽一切努力使用前面八个模式之一。
元模式：找到复杂性并减少变化
当我们指导团队更有效地分解故事时，我们发现了这些模式共有的元模式：关注复杂性并通过其减少变化。这是直接使用元模式的方法：
找到核心复杂性。什么是最可能使您感到惊讶或出现问题的部分？这通常取决于人的喜好或行为。有时，这是具有新集成或外部依赖关系的部分。
识别差异。有很多？业务规则，用户类型，界面，数据变体，实体等。
将所有变化减少到一个。在复杂的部分中找到一个完整的切片。这可能是一个场景。也可能是通过单个业务规则变体产生的一系列场景。
大多数故事拆分模式只是识别变异源并将其减少为一个示例。
这种方法对于新事物的第一部分特别有效，因为它直接解决了核心复杂性，并且避免了其他任何事情都会使工作变得更大。
步骤3：评估分割
您经常会发现可以使用几种模式拆分故事。您应该选择哪个拆分？我们使用两个经验法则：
选择拆分，使您可以取消优先处理或丢弃故事。80/20原则表明，用户故事的大部分价值都来自功能的一小部分。当一个分类显示低价值的功能而另一分类则不显示低价值功能时，则表明后者显示了每个小故事中的浪费。进行拆分，使您可以丢弃低价值的东西。
选择可以使您获得大小相等的小型故事的拆分。将一个8点故事转换为四个2点故事的拆分比生成5点和3点的故事更有用。它为产品所有者提供了更大的自由，可以分别对功能的各个部分进行优先级排序。
可能需要花费一些尝试才能找到最适合您尝试拆分的故事的模式-您可能需要尝试以找到正确的模式。
Cynefin和故事分裂
戴夫·斯诺登（Dave Snowden）的Cynefin模型是一种根据问题的复杂性来考虑问题的正确策略的有用方法。我们发现Cynefin非常有用，我们将其包含在几乎所有研讨会中，都作为必备内容或研讨会本身。如果您还不熟悉该模型，请查看我们的概述。
每个Cynefin域的故事拆分看起来都不同。这是如何做：
显而易见–只需构建它即可。或者，如果太大，则查找所有故事，并先做最有价值的故事。
复杂-找到所有故事，并首先做最有价值和/或最具风险的故事。
复杂–不要尝试查找所有故事。找到一两个会提供一些价值的东西，并教给您有关问题和解决方案的一些知识，建立这些知识并利用您学到的知识找到其余的知识。
混乱–扑灭大火；现在，拆分故事可能并不重要。
乱序-分割之前先确定您所在的域，以免采取错误的方法。
最重要的细微差别是在复杂的领域，从那里开始工作会教会您有关工作的知识。在这种情况下，试图找到所有构成原始大故事的小故事是没有意义的。相反，找到一个或两个即可立即开始学习的效率更高。
有些人对此方法感到不舒服，希望列举所有故事并确定其大小，以便能够将时间计划在积压的项目上。但是，如果您确实处于复杂领域中，那么这只会给您带来可预测性的幻觉-实际的故事可能会随着您的工作而发生变化。最好对复杂工作中固有的不确定性保持透明。
善于故事分解
就像我们之前说过的那样，在较薄的垂直切片中工作是敏捷软件开发的主要习惯。许多人都在努力寻找垂直切片，但这是一项非常可学的技能。团队只需花费约2.5至3个小时的练习，便可以从苦苦挣扎，轻松地确定其领域内的特征和大故事的片段。当然，练习时间的质量很重要。我建议这样做的方式…
在一周或两周的时间内安排两个或三个1小时的练习课。邀请整个团队或至少将业务和技术观点很好地融合在一起。
要准备第一期会议，请查看最近几个月来您最近的积压工作。选择一些您难以拆分但已成功实现的故事或功能。
用Cynefin术语来说，这些完成的功能现在已被排序（复杂或显而易见），因为出现的订单足以实现它们。未来的工作可能很复杂且无序。但这现在并不重要。在此第一次练习中，您的目标是确定在您的域中使功能变大的模式。返回已完成的工作是提高实践效率的关键。
在此第一次练习中，选择您选择的功能或故事之一，然后逐步讲解故事拆分流程图中的问题。假装该功能尚未实现，但让您自己了解有关此功能的知识。
如果您找到其中一种模式的良好分割，请不要停止。继续浏览其他模式，并尝试查找其他可能的拆分。
如果一次拆分无法产生足够小的故事，请尝试进一步拆分这些故事。
大约50分钟后，停止。对于流程图上的每个故事拆分模式，请查看您在自己的工作中发现的示例。
如果您在本次会议中没有找到模式的示例，请花点时间集思广益，回顾一下您过去的工作中的示例。您正试图让人们共同了解这些模式在您的域中显示时的外观。
如果在第一届会议结束之前拆分完成的功能似乎很容易，那么您就可以继续进行后续工作了。如果不是，则坚持完成的项目再久一些。在您下次练习之前，请找到一些合适的功能。在该会话中，重复上述过程。
困难的部分是您实际上必须将其视为实践。人们通常不愿花时间去通过正式培训或通过做功来学习技能以外的其他方法来发展技能。团队有时会花时间练习拆分旧功能，因为该活动不会产生新的工作输出，例如，它不会完善即将到来的积压工作。但是，实践的这一方面是技能开发中收益最大的部分。不要跳过它。
在这些课程的2至3节之后，您应该到达一个所有人都可以描述工作中每个模式的示例的地步，并迅速集中精力于将来工作的适当模式。
垂直切片和比例
当一个产品上有100多个人员时，可以使用垂直切片吗？
当多个敏捷团队在一个产品上一起工作时，可以采用两种主要的组织方式：功能团队或组件团队。
特征团队经过组织，因此每个团队都具有足够的跨职能部门，可以在部分或全部产品上交付完整的价值片段（即“垂直片段”）。根据产品的大小，功能团队可能会专门研究产品的某些部分，从而有效地创建子产品，或者他们可能能够处理整个产品中最重要的部分。
另一方面，组件团队的组织方式是，每个团队专注于特定的组件，体系结构层或技术。交付完整的价值片段需要多个团队共同努力。
让我们考虑一个相当大的业务应用程序的特定示例：QuickBooks Online会计产品。（注意：我们不知道Intuit的QuickBooks团队的实际组织方式或技术是什么样，并且现在并不重要。我们只需要一个熟悉的软件产品即可进行推理。）
QuickBooks Online具有Web前端。我们假定它可能通过某种服务接口与某种后端通信。有一些批处理过程，例如从银行提取交易，处理工资单，支付账单以及用税做各种事情。
例如，使用组件团队结构，您将拥有Web团队，他们可以更改Web用户界面，但可能依赖后端团队对其系统部分进行相应更改。各个团队之间的协调将集中于确保他们的工作协调一致以提供价值。
使用功能团队结构，您可能有一个团队或一小组小组负责用户体验的总帐部分，另一个负责报告，另一个负责工资单。这些团队中的每一个都将在其团队中具有前端和后端技能。在这种情况下，各个团队之间的协调将集中于确保设计和体系结构在整个产品中保持一致。
相同的产品，但团队共同为两种不同的结果和折衷方案组织了两种不同的方式。
因此，垂直切片是否在规模上相关的问题的答案取决于您的组织方式。组成团队是一个明确的决定，不按垂直方向工作。组件团队可以围绕较大的垂直切片（如MMF）协调工作，但是在工作项目级别，他们缺乏完成团队中垂直切片所需的交叉功能。换句话说，组建组件团队有意放弃上面的结果列表，以便针对其他方面进行优化（通常更容易进行架构调整或提高对专业技术技能的利用）。
功能团队当然会做出相反的权衡。它们旨在提供垂直切片，并获得我们上面列出的所有优势（以及需要明确协调架构对齐的成本）。
功能团队与组件团队是有关主要组织方法的。自然地，存在细微差别和混杂，并且随着时间的流逝而变化。我们之前已经写过关于这一点的文章，特别是在使用大量旧产品改造组织的情况下。
您是否应该有100多个人员在开发单个产品？
现在，我们心中还有一个更重要的问题，那就是：不管我们是否可以在大型产品或项目中使用垂直切片-正如我们所展示的，如果我们在功能团队中进行组织，是否可以-这么多人一次努力实际上有效吗？
添加到单个产品（或项目）中的每个人或团队都会带来一些生产力和一些协调开销。一个人的项目几乎是纯粹的生产力。再增加一个人，您的工作效率就不会提高一倍，您的工作效率会有所提高，但是现在两个人的时间中有一部分专门用于协调工作。添加第三个人，您将再次获得生产率的提高以及协调开销的增加。这种协调负担随着人与人之间联系的数量呈指数增长。
我们通过组织团队来在某种程度上减轻这种情况，以便每个人只需要与少量人员协调工作细节，并尝试将工作划分到各个团队之间以最大程度地减少依赖性。但是工作越复杂，依赖关系就越难以预测，团队之间需要进行协调的可能性就越大。
因此，在某个时候，增加另一个人或团队不仅不能增加生产率的提高，而且会在整个系统上增加协调成本，从而使总体生产率下降。
确切地讲，此点高度依赖于上下文。但是曲线的形状至少应该使我们对大型项目感到怀疑，并且不愿意增加人员或团队。
对于复杂的工作尤其如此，在工作过程中我们很可能会了解问题和解决方案。在软件开发中，复杂性似乎与价值高度相关。如果有价值，那么它可能还不存在。如果是新产品，我们在工作中很可能会学到一些东西。
垂直切片的底线刻度
是的，您可以在每个细节级别上进行垂直切片，并进行大小工作，这样做具有很大的价值。但是在更大的范围内，您需要以特定的方式进行组织：在功能团队中，或在强调功能交付的某种混合形式中。当您使用它时，值得考虑的是，这么大的尺寸是否真正满足了您的需求。