《敏捷快速入门指南》简要概述了我在与团队合作时发现的有效方法，对于那些希望获得一些一般性指南（并非旨在作为说明性准则，但可以作为任何团队工作的基准。大多数快速入门指南都集中在与Scrum相关的主题（Scrum事件）上。其他主题涵盖了作为敏捷教练经常遇到的领域。
Scrum主题
其他主题：
简介：产品列表梳理会议（也称为需求梳理）不是Scrum指南中定义的活动。然而，产品列表梳理的实践在Scrum团队中是非常普遍，以至于一些从业者认为这是普遍接受的Scrum实践。
产品列表梳理会议是为即将到来的（如接下来的1-2个）迭代（Sprint）准备用户故事的一个持续过程。产品列表梳理有两个主要方面：
注意：某些团队选择每个Sprint进行多次"梳理"会话。如2周的SPrint，可能一周梳理1次。
团队应努力在一个小时或更短的时间内完成为期两周的Sprint的产品列表梳理。当故事在产品列表梳理开始之前就被很好地阐明时，团队更有可能在相当短的时间内完成产品列表梳理。（另请参见编写清晰明确的用户故事快速入门指南。）
产品列表梳理期间的活动通常包括：
注意：另请参阅多年前我写的产品列表梳理
每日Scrum（又称每日站会）是开发团队通过简短的、有针对性的对话来确保他们每天保持一致。每日Scrum期间发生的主要事情：
每天一次（一般SPrint第一天除外，因为已经有了计划会）；每天同一时间、同一地点，会降低复杂度。
每日Scrum的持续时间不得超过15分钟。
注意： 与会者按重要性顺序列出：每日Scrum用于开发团队，因此会议属于团队的。Scrum Master通常作为主持人出现。但是，团队中的不同成员轮流担任主持人也很常见（不一定只有ScrumMaster来主持）。对于产品负责人而言，阐明可能出现的任何与产品相关的问题也可能会有帮助。
“每日站会程序"的示例如下：
注意：另请参阅Scrum会议的输入输出
Sprint计划会议旨在确保对即将开始的Sprint期间团队计划进行的工作有完全的了解。Sprint计划有几个关键方面：
每个迭代一次（即迭代的第一天）
假设在Sprint Planning开始之前已经完成了产品列表梳理，那么许多团队都可以在一个小时或更短的时间内完成Sprint Planning。Sprint期间要完成的工作的不确定性越高，Sprint计划花费的时间就越长。
Sprint评审会议旨在确保完全清楚地说明团队在Sprint期间完成的工作以及他们接下来将要开展的工作。Sprint评论有几个关键方面：
由于形式不同，比如单团队Sprint评审或多团队Sprint评审，因此此类会议的时间可能会有很大的不同，从单个团队的30分钟到多个团队的几小时都是可能的。
Sprint回顾是团队进行公开而诚实的对话的机会，对话通常集中于团队在Sprint中所做的工作。Sprint回顾本质就是团队级别的Kaizen（或持续改进）。
每个迭代一次（迭代的最后一天，最后一个活动）
团队的氛围在Sprint回顾的过程中起着重要作用。对于刚起步的团队，或者发现团队需要面对重大挑战的情况，可能需要花最少一个小时的时间。其他时候，则30分钟足够。
（+）一些敏捷从业者建议，产品负责人没有必要（甚至不希望）参加Sprint回顾。鉴于产品负责人，ScrumMaster和开发团队之间的关系非常重要，因此作为惯例，产品负责人参与回顾会，很可能会帮助该团队。
（++）为了心理安全，只有开发团队，Scrum Master和产品负责人的成员参加Sprint回顾是一种标准做法。
（+++）团队经常在Sprint回顾会议上讨论很多事情。但是，团队在Sprint回顾会议上谈论的内容属于机密信息，不会分享给其他人。另外，团队的改进相关的任何行动步骤，通常对其他人可见。
无论我们发现什么，我们始终理解并坚信，鉴于团队当时所知道的信息、技能、能力和可用的资源以及当前的情况，每个人都已经尽了最大的努力。
（+）引导回顾会议的方法非常多。每个团队每个SPrint都不一样，因此作为SCrumMaster需要有一个工具箱来引导回顾会。
发邮件索取引导回顾的工具箱 bob@bobjiang.com
这里讨论的拆分模式是：
假设某个特定的故事是基于完整的工作流程。因此，此模式沿工作流中各个步骤将较大的故事拆分开，例如：
这种模式试图将特定故事中存在的业务规则分开，以寻找机会根据这些业务规则之间的差异来拆分故事。以下是一些示例业务规则：
使用简单/复杂模式，寻找机会修改非常笼统的故事（这通常掩盖了复杂性）。尝试为每部分定义验收标准有助于简化此过程。例如，
可能会通过诸如……的方式变得更加具体。
在这种模式下，焦点转移到数据对象上。与团队合作，根据用户角色和操作选择数据对象的选项。假设有称为"产品"，“付款"和"收据"的数据对象。在这种情况下，想法是针对每种对象类型专注于特定的数据类型。因此，对于"产品”，可能会有诸如Book，DVD和Gift Card之类的数据类型。
然后，您可以与产品负责人一起确定具有最高业务价值的数据类型，并据此拆分故事。故事中的复杂性可能来自处理数据的变化。
有时用户界面本身会显示复杂性。在这种情况下，可以用UI的方式来拆分故事，然后再构建更高级的UI。当然，这些不是独立的。如果您先做第二个故事，那么第二个故事实际上就是原始故事。但这仍然是有用的拆分。
可以修改上面的故事，以限定可能需要什么样的用户输入，如下所示：
在这种模式下，想法是寻找机会推迟使现有故事变得异常庞大的工作。试图通过一个故事来实现特定的性能目标可能会使其变得很大。通常最好将系统性能视为需要更广泛解决的全局条件（例如，作为"完成的定义"的一部分）。
以下是"非功能性"需求的一些其他示例，通常最好分开考虑：
注意：我不是说，上述定义的"完成的订义"注意事项并不重要；我们在这里要避免的是尝试通过单个用户故事解决此类问题。
在这种模式下，尝试着眼于操作和过程。一些团队可能从CRUD（增删改查）方案的角度来看待此问题，例如：
如果上述故事仍然太大，则可以根据如下CRUD操作将其进一步拆分：
另一个常用的经验法则是注意通用动词，例如"管理"。例如，如果有一个用户故事说"作为一名新学生，我想管理我的帐户…"，“管理"一词往往会掩盖更具体的操作，例如"取消帐户，编辑帐户”，以及以此类推。
一个故事可能不是很大，不是因为一定很复杂，而是因为对实现的了解不多（未知领域）。首先执行时间限制（如1-2天），以解决实施过程中的不确定性。然后，您可以执行实现或更好地了解如何分解它。假设您不确定要采用哪种技术方法来实现以下故事：
您可以先从一个探针（SPike）开始：
然后继续执行上面所述的故事（假设故事足够小，不需要先拆分即可。）
在"选择技术"的过程中，验收标准应该是您需要回答的问题。做足够的调查就可以停止；否则很容易迷失方向进行研究。
探针模式是最后一个，因为它应该是最后的选择。您可能知道足够的知识来构建。这样做（探针），您将了解更多。因此，在采用探针模式之前，请尽一切努力使用前面八个模式之一。
您需要询问以下几个问题来确定原始故事是否已被拆分，以及拆分后的故事是否需要进一步处理：
在编写用户故事时，请努力确保每个用户故事都满足所有INVEST属性，其中INVEST代表：
独立的 Independent
可商谈的 Negotiable
有价值的 Valuable
可估算的 Estimable
较小的 Small
可测试的 Testable
独立的 – 在最大程度上，一个用户故事应该与另一个用户故事无关。这对于同一Sprint中正在处理的故事特别重要，因为故事之间的依赖性会使计划、优先级排序以及估算变得更加困难。尽可能在Sprint中来拆分或修改故事以减少或消除依赖性。
可商谈的 – 用户故事是可协商的，因为实际的故事卡（或其电子表示形式）旨在作为与将要构建的团队的"对话邀请"。与故事相关的详细信息在此对话期间得以解决。
有价值的 – 每个故事的用词很重要，以使与故事相关的商业价值显而易见。这就是产品负责人在帮助团队了解用户故事的"为什么"和"什么"方面起如此重要作用的原因。与每个故事相关的技术细节（“如何”）可在与该故事相关的描述性细节或单个任务中找到，并且团队根据对"为什么"和"故事"的理解来确定"如何做"
可估算的 – 至少故事需要足够清晰，以使团队能够对故事的相对大小进行初步估计。可能会影响团队评估能力的常见问题包括：缺乏领域知识（这就是为什么围绕故事的"对话"如此重要）以及过大的故事（在这种情况下，故事需要拆分为多个小故事）。
较小的 – 从最基本的角度讲，故事必须足够小才能在Sprint中完成。根据团队的规模，迭代的时间长短和其他因素，团队通常将故事拆分得足够小，以便至少可以在一个迭代中完成六个（通常更多的）故事。简而言之，较大的故事会给团队带来麻烦，因为较大的故事代表这更多的不确定性，以及思考的深度不够。
可测试的 – 如果故事无法测试，则团队几乎不可能（更不用说产品负责人）知道故事何时"完成"。一个经典的反模式是当故事包含诸如"易于使用"之类的不精确的语言时（因为没有直接的方法可以测试易用性）。因此，需要以一种可以容易地从中得出测试方法的方式来编写验收标准。
本快速入门指南中的内容基于Richard Lawrence在其博客上观察和编译的模式。这个博客上也有一篇我翻译的中文的拆分模式。
团队通常难以编写清楚传达以下内容的用户故事：
注意：常见的误解是，编写用户故事的唯一责任在于产品负责人（或产品负责人的代理人）。尽管大多数情况下是产品负责人起草用户故事，但让团队成员参与编写和完善用户故事这很重要，因为当团队参与此活动时，每个人对什么内容会有相同理解，并且我们也知道为什么要构建以及我们如何知道何时完成。
各个部分介绍了明确表达的用户故事的每个主要组成部分：
就像其他类型的标题（又称标题）一样，故事标题应该简短，因为简短的陈述……
对于故事标题，建议使用以下格式：（角色）（动作）（上下文）
例如：
其中 …（角色）=主要申请人 （操作）=输入密码
注意：（角色）和（动作）是必需的，而（上下文）在标题中是可选的。例如，当有许多标题相似的用户故事时，添加上下文可以帮助区分它们。在上面的示例中，用户可能会在正在构建的应用程序的不同位置输入密码，或者可能存在不止一种密码。在这种情况下，添加上下文可以增加清晰度，例如"主要申请人输入密码（页面类型），或主要申请人输入密码（密码类型）。
故事描述的规范格式如下所述。编写故事说明时，请记住以下几点。考虑投入和产出：
考虑垂直切片：
考虑可以传达故事意图的最少单词数：
故事描述的规范格式为
例如：
用户故事的优先级由其在产品待办事项列表中的相对位置以及在Sprint待办事项列表中的相对位置反映（最接近列表顶部的用户故事具有最高优先级）。
在列表的待办事项中优先考虑项目的相对优先级不是浪费时间，例如，用户故事的优先级是50还是51。更加重要的是要弄清积压的前10至20个条目。可以节省优先级时间的决策工具称为"金字塔列表"。
注意：" Jira优先级"字段提供了许多其他选项，可以指示任何给定工作条目的相对重要性。本快速入门指南不涉及" Jira Priority"字段的用法。
当敏捷团队估算规模时，他们会采用"相对估算"。之所以称为相对估算，是因为我们关注的是事物A相对于事物B的相对大小，或事物B相对于事物C的相对大小，等等。
注意：实际上，选择进行估算的团队通常在进行相对估算时会使用T恤尺寸作为起点。
对于使用故事点进行估算的团队，最常见的是仅使用斐波那契数列中的数字进行故事点估算：1、2、3、5、8、13…
正如花了很多时间来构建软件的任何人所能证明的那样，准确估算我们所构建的任何东西的规模都是一个难题，并且批次的大小（无论是功能还是版本）越大，其不确定性和风险就越大。（因此要保持小批次，有助于降低复杂性和风险。）
使用斐波那契数列已变得很流行，因为这样做可以帮助强化估算永远不准确的观念。例如，当我们考虑将一个用户故事的大小定为3个故事点，并将一个用户故事的大小定为5个故事点时，我们可以肯定地说的就是，基于现在知道，完成5个故事点比完成3个故事点需要做更多的工作。
使用斐波那契数列的另一个吸引人的方面是，数字越大，它们之间的差距越大，这表明随着工作项目变大，不确定性和风险趋于迅速增加。
精益敏捷社区中的一些从业者建议，花时间进行估算是一种浪费。（特别是在精益管理中，着重于将无法带来业务价值的任何活动减至最小。花时间进行估算，尤其是当团队花过多时间在估算时，该活动就是浪费。）
有些人可能想知道，如果团队不估算列表的工作条目的相对大小，他们将如何预测何时完成特定工作。这些团队的答案通常是简单的：如果需要计算速度，而不是计算故事点，只需计算完成的工作条目的数量。例如，如果一个团队在Sprint 1中完成10个故事，在Sprint 2中完成12个故事，在Sprint 3中完成15个故事，那么他们的速度分别是10，然后是12，然后是15。
注意：在没有估算的情况下取得成功的团队往往也会擅长将工作项分解成相当小的部分，其中最大的部分可能不会花费几天就能完成，一般来讲一个故事1-2天即可完成。本着检视和调整的精神，他们如何估算以及是否估算，可能是团队进行试验的领域。
对于要视为完成的任何用户故事，都需要满足其验收标准，并且需要与"完成的定义"中存在的所有全局规定保持一致。
阐明验收标准的目的的一种简单方法是：验收标准指导测试策略，使我们能够（通过测试）证明用户的故事已达到预期目的。
注意：验收标准通常不会直接映射到Jira中的特定字段（取决于Jira的配置方式）。
在Jira中纳入验收标准的方法示例包括：
有多种编写验收标准的方法。注意：就本快速入门指南而言，我们仅描述验收标准的"测试……“格式。
以下是以"测试……“格式编写的测试的几个示例：
与故事标题和故事描述相反，故事标题和故事描述关注于谁，什么以及为什么，而技术方法（与验收标准一起）则关注如何做。
注意：通常，属于技术方法的工件会作为附件，链接或子任务映射到Jira。
由于技术方法可能会因产品而有很大差异，因此很难为技术故事指定特定格式。以下是一些常见的准则：
注意：Jira（和许多其他工具）支持输入与任务相关的时间（通常以小时为单位）的实践。许多敏捷从业者认为任务的输入（跟踪小时数）是浪费，更不用说任务持续时间（即"烧掉"时间）了。换句话说，要重点关注的是功能完成，而不是花费时间。
《敏捷快速入门指南》简要概述了我在与团队合作时发现的有效方法，对于那些希望获得一些一般性指南（并非旨在作为说明性准则，但可以作为任何团队工作的基准。大多数快速入门指南都集中在与Scrum相关的主题（Scrum事件）上。其他主题涵盖了作为敏捷教练经常遇到的领域。
Scrum主题
其他主题：
简介：产品列表梳理会议（也称为需求梳理）不是Scrum指南中定义的活动。然而，产品列表梳理的实践在Scrum团队中是非常普遍，以至于一些从业者认为这是普遍接受的Scrum实践。
产品列表梳理会议是为即将到来的（如接下来的1-2个）迭代（Sprint）准备用户故事的一个持续过程。产品列表梳理有两个主要方面：
注意：某些团队选择每个Sprint进行多次"梳理"会话。如2周的SPrint，可能一周梳理1次。
团队应努力在一个小时或更短的时间内完成为期两周的Sprint的产品列表梳理。当故事在产品列表梳理开始之前就被很好地阐明时，团队更有可能在相当短的时间内完成产品列表梳理。（另请参见编写清晰明确的用户故事快速入门指南。）
产品列表梳理期间的活动通常包括：
注意：另请参阅多年前我写的产品列表梳理
每日Scrum（又称每日站会）是开发团队通过简短的、有针对性的对话来确保他们每天保持一致。每日Scrum期间发生的主要事情：
每天一次（一般SPrint第一天除外，因为已经有了计划会）；每天同一时间、同一地点，会降低复杂度。
每日Scrum的持续时间不得超过15分钟。
注意： 与会者按重要性顺序列出：每日Scrum用于开发团队，因此会议属于团队的。Scrum Master通常作为主持人出现。但是，团队中的不同成员轮流担任主持人也很常见（不一定只有ScrumMaster来主持）。对于产品负责人而言，阐明可能出现的任何与产品相关的问题也可能会有帮助。
“每日站会程序"的示例如下：
注意：另请参阅Scrum会议的输入输出
Sprint计划会议旨在确保对即将开始的Sprint期间团队计划进行的工作有完全的了解。Sprint计划有几个关键方面：
每个迭代一次（即迭代的第一天）
假设在Sprint Planning开始之前已经完成了产品列表梳理，那么许多团队都可以在一个小时或更短的时间内完成Sprint Planning。Sprint期间要完成的工作的不确定性越高，Sprint计划花费的时间就越长。
Sprint评审会议旨在确保完全清楚地说明团队在Sprint期间完成的工作以及他们接下来将要开展的工作。Sprint评论有几个关键方面：
由于形式不同，比如单团队Sprint评审或多团队Sprint评审，因此此类会议的时间可能会有很大的不同，从单个团队的30分钟到多个团队的几小时都是可能的。
Sprint回顾是团队进行公开而诚实的对话的机会，对话通常集中于团队在Sprint中所做的工作。Sprint回顾本质就是团队级别的Kaizen（或持续改进）。
每个迭代一次（迭代的最后一天，最后一个活动）
团队的氛围在Sprint回顾的过程中起着重要作用。对于刚起步的团队，或者发现团队需要面对重大挑战的情况，可能需要花最少一个小时的时间。其他时候，则30分钟足够。
（+）一些敏捷从业者建议，产品负责人没有必要（甚至不希望）参加Sprint回顾。鉴于产品负责人，ScrumMaster和开发团队之间的关系非常重要，因此作为惯例，产品负责人参与回顾会，很可能会帮助该团队。
（++）为了心理安全，只有开发团队，Scrum Master和产品负责人的成员参加Sprint回顾是一种标准做法。
（+++）团队经常在Sprint回顾会议上讨论很多事情。但是，团队在Sprint回顾会议上谈论的内容属于机密信息，不会分享给其他人。另外，团队的改进相关的任何行动步骤，通常对其他人可见。
无论我们发现什么，我们始终理解并坚信，鉴于团队当时所知道的信息、技能、能力和可用的资源以及当前的情况，每个人都已经尽了最大的努力。
（+）引导回顾会议的方法非常多。每个团队每个SPrint都不一样，因此作为SCrumMaster需要有一个工具箱来引导回顾会。
发邮件索取引导回顾的工具箱 bob@bobjiang.com
这里讨论的拆分模式是：
假设某个特定的故事是基于完整的工作流程。因此，此模式沿工作流中各个步骤将较大的故事拆分开，例如：
这种模式试图将特定故事中存在的业务规则分开，以寻找机会根据这些业务规则之间的差异来拆分故事。以下是一些示例业务规则：
使用简单/复杂模式，寻找机会修改非常笼统的故事（这通常掩盖了复杂性）。尝试为每部分定义验收标准有助于简化此过程。例如，
可能会通过诸如……的方式变得更加具体。
在这种模式下，焦点转移到数据对象上。与团队合作，根据用户角色和操作选择数据对象的选项。假设有称为"产品"，“付款"和"收据"的数据对象。在这种情况下，想法是针对每种对象类型专注于特定的数据类型。因此，对于"产品”，可能会有诸如Book，DVD和Gift Card之类的数据类型。
然后，您可以与产品负责人一起确定具有最高业务价值的数据类型，并据此拆分故事。故事中的复杂性可能来自处理数据的变化。
有时用户界面本身会显示复杂性。在这种情况下，可以用UI的方式来拆分故事，然后再构建更高级的UI。当然，这些不是独立的。如果您先做第二个故事，那么第二个故事实际上就是原始故事。但这仍然是有用的拆分。
可以修改上面的故事，以限定可能需要什么样的用户输入，如下所示：
在这种模式下，想法是寻找机会推迟使现有故事变得异常庞大的工作。试图通过一个故事来实现特定的性能目标可能会使其变得很大。通常最好将系统性能视为需要更广泛解决的全局条件（例如，作为"完成的定义"的一部分）。
以下是"非功能性"需求的一些其他示例，通常最好分开考虑：
注意：我不是说，上述定义的"完成的订义"注意事项并不重要；我们在这里要避免的是尝试通过单个用户故事解决此类问题。
在这种模式下，尝试着眼于操作和过程。一些团队可能从CRUD（增删改查）方案的角度来看待此问题，例如：
如果上述故事仍然太大，则可以根据如下CRUD操作将其进一步拆分：
另一个常用的经验法则是注意通用动词，例如"管理"。例如，如果有一个用户故事说"作为一名新学生，我想管理我的帐户…"，“管理"一词往往会掩盖更具体的操作，例如"取消帐户，编辑帐户”，以及以此类推。
一个故事可能不是很大，不是因为一定很复杂，而是因为对实现的了解不多（未知领域）。首先执行时间限制（如1-2天），以解决实施过程中的不确定性。然后，您可以执行实现或更好地了解如何分解它。假设您不确定要采用哪种技术方法来实现以下故事：
您可以先从一个探针（SPike）开始：
然后继续执行上面所述的故事（假设故事足够小，不需要先拆分即可。）
在"选择技术"的过程中，验收标准应该是您需要回答的问题。做足够的调查就可以停止；否则很容易迷失方向进行研究。
探针模式是最后一个，因为它应该是最后的选择。您可能知道足够的知识来构建。这样做（探针），您将了解更多。因此，在采用探针模式之前，请尽一切努力使用前面八个模式之一。
您需要询问以下几个问题来确定原始故事是否已被拆分，以及拆分后的故事是否需要进一步处理：
在编写用户故事时，请努力确保每个用户故事都满足所有INVEST属性，其中INVEST代表：
独立的 Independent
可商谈的 Negotiable
有价值的 Valuable
可估算的 Estimable
较小的 Small
可测试的 Testable
独立的 – 在最大程度上，一个用户故事应该与另一个用户故事无关。这对于同一Sprint中正在处理的故事特别重要，因为故事之间的依赖性会使计划、优先级排序以及估算变得更加困难。尽可能在Sprint中来拆分或修改故事以减少或消除依赖性。
可商谈的 – 用户故事是可协商的，因为实际的故事卡（或其电子表示形式）旨在作为与将要构建的团队的"对话邀请"。与故事相关的详细信息在此对话期间得以解决。
有价值的 – 每个故事的用词很重要，以使与故事相关的商业价值显而易见。这就是产品负责人在帮助团队了解用户故事的"为什么"和"什么"方面起如此重要作用的原因。与每个故事相关的技术细节（“如何”）可在与该故事相关的描述性细节或单个任务中找到，并且团队根据对"为什么"和"故事"的理解来确定"如何做"
可估算的 – 至少故事需要足够清晰，以使团队能够对故事的相对大小进行初步估计。可能会影响团队评估能力的常见问题包括：缺乏领域知识（这就是为什么围绕故事的"对话"如此重要）以及过大的故事（在这种情况下，故事需要拆分为多个小故事）。
较小的 – 从最基本的角度讲，故事必须足够小才能在Sprint中完成。根据团队的规模，迭代的时间长短和其他因素，团队通常将故事拆分得足够小，以便至少可以在一个迭代中完成六个（通常更多的）故事。简而言之，较大的故事会给团队带来麻烦，因为较大的故事代表这更多的不确定性，以及思考的深度不够。
可测试的 – 如果故事无法测试，则团队几乎不可能（更不用说产品负责人）知道故事何时"完成"。一个经典的反模式是当故事包含诸如"易于使用"之类的不精确的语言时（因为没有直接的方法可以测试易用性）。因此，需要以一种可以容易地从中得出测试方法的方式来编写验收标准。
本快速入门指南中的内容基于Richard Lawrence在其博客上观察和编译的模式。这个博客上也有一篇我翻译的中文的拆分模式。
团队通常难以编写清楚传达以下内容的用户故事：
注意：常见的误解是，编写用户故事的唯一责任在于产品负责人（或产品负责人的代理人）。尽管大多数情况下是产品负责人起草用户故事，但让团队成员参与编写和完善用户故事这很重要，因为当团队参与此活动时，每个人对什么内容会有相同理解，并且我们也知道为什么要构建以及我们如何知道何时完成。
各个部分介绍了明确表达的用户故事的每个主要组成部分：
就像其他类型的标题（又称标题）一样，故事标题应该简短，因为简短的陈述……
对于故事标题，建议使用以下格式：（角色）（动作）（上下文）
例如：
其中 …（角色）=主要申请人 （操作）=输入密码
注意：（角色）和（动作）是必需的，而（上下文）在标题中是可选的。例如，当有许多标题相似的用户故事时，添加上下文可以帮助区分它们。在上面的示例中，用户可能会在正在构建的应用程序的不同位置输入密码，或者可能存在不止一种密码。在这种情况下，添加上下文可以增加清晰度，例如"主要申请人输入密码（页面类型），或主要申请人输入密码（密码类型）。
故事描述的规范格式如下所述。编写故事说明时，请记住以下几点。考虑投入和产出：
考虑垂直切片：
考虑可以传达故事意图的最少单词数：
故事描述的规范格式为
例如：
用户故事的优先级由其在产品待办事项列表中的相对位置以及在Sprint待办事项列表中的相对位置反映（最接近列表顶部的用户故事具有最高优先级）。
在列表的待办事项中优先考虑项目的相对优先级不是浪费时间，例如，用户故事的优先级是50还是51。更加重要的是要弄清积压的前10至20个条目。可以节省优先级时间的决策工具称为"金字塔列表"。
注意：" Jira优先级"字段提供了许多其他选项，可以指示任何给定工作条目的相对重要性。本快速入门指南不涉及" Jira Priority"字段的用法。
当敏捷团队估算规模时，他们会采用"相对估算"。之所以称为相对估算，是因为我们关注的是事物A相对于事物B的相对大小，或事物B相对于事物C的相对大小，等等。
注意：实际上，选择进行估算的团队通常在进行相对估算时会使用T恤尺寸作为起点。
对于使用故事点进行估算的团队，最常见的是仅使用斐波那契数列中的数字进行故事点估算：1、2、3、5、8、13…
正如花了很多时间来构建软件的任何人所能证明的那样，准确估算我们所构建的任何东西的规模都是一个难题，并且批次的大小（无论是功能还是版本）越大，其不确定性和风险就越大。（因此要保持小批次，有助于降低复杂性和风险。）
使用斐波那契数列已变得很流行，因为这样做可以帮助强化估算永远不准确的观念。例如，当我们考虑将一个用户故事的大小定为3个故事点，并将一个用户故事的大小定为5个故事点时，我们可以肯定地说的就是，基于现在知道，完成5个故事点比完成3个故事点需要做更多的工作。
使用斐波那契数列的另一个吸引人的方面是，数字越大，它们之间的差距越大，这表明随着工作项目变大，不确定性和风险趋于迅速增加。
精益敏捷社区中的一些从业者建议，花时间进行估算是一种浪费。（特别是在精益管理中，着重于将无法带来业务价值的任何活动减至最小。花时间进行估算，尤其是当团队花过多时间在估算时，该活动就是浪费。）
有些人可能想知道，如果团队不估算列表的工作条目的相对大小，他们将如何预测何时完成特定工作。这些团队的答案通常是简单的：如果需要计算速度，而不是计算故事点，只需计算完成的工作条目的数量。例如，如果一个团队在Sprint 1中完成10个故事，在Sprint 2中完成12个故事，在Sprint 3中完成15个故事，那么他们的速度分别是10，然后是12，然后是15。
注意：在没有估算的情况下取得成功的团队往往也会擅长将工作项分解成相当小的部分，其中最大的部分可能不会花费几天就能完成，一般来讲一个故事1-2天即可完成。本着检视和调整的精神，他们如何估算以及是否估算，可能是团队进行试验的领域。
对于要视为完成的任何用户故事，都需要满足其验收标准，并且需要与"完成的定义"中存在的所有全局规定保持一致。
阐明验收标准的目的的一种简单方法是：验收标准指导测试策略，使我们能够（通过测试）证明用户的故事已达到预期目的。
注意：验收标准通常不会直接映射到Jira中的特定字段（取决于Jira的配置方式）。
在Jira中纳入验收标准的方法示例包括：
有多种编写验收标准的方法。注意：就本快速入门指南而言，我们仅描述验收标准的"测试……“格式。
以下是以"测试……“格式编写的测试的几个示例：
与故事标题和故事描述相反，故事标题和故事描述关注于谁，什么以及为什么，而技术方法（与验收标准一起）则关注如何做。
注意：通常，属于技术方法的工件会作为附件，链接或子任务映射到Jira。
由于技术方法可能会因产品而有很大差异，因此很难为技术故事指定特定格式。以下是一些常见的准则：
注意：Jira（和许多其他工具）支持输入与任务相关的时间（通常以小时为单位）的实践。许多敏捷从业者认为任务的输入（跟踪小时数）是浪费，更不用说任务持续时间（即"烧掉"时间）了。换句话说，要重点关注的是功能完成，而不是花费时间。