前言
这一系列文章是《Fifty Quick Ideas To Improve Your User Stories》一书的读书笔记与摘要。
创建故事
1. “讲”故事，而不是“写”故事。
不应该把用户故事看成是轻量级的需求文档。开发团队被动地从业务代表手中接受需求文档，无论这文档是写在纸上的还是在某种需求跟踪系统中的，这都不是真正的“用户故事”的需求分析方法。采用这种过程的组织无法获取迭代开发的所有好处。
“用户故事”暗含着一种全新的模式：通过协同工作来（分析）需求。
关于用户的需要和解决方案的有效的讨论对于短迭代周期来说至关重要，因为没有足够的时间让任何人坐下来把所有的东西都写成文档。当然，即使对于较长的交付周期来说“将一切文档化”也很少有用，只是人们常常会假装来做这件事。当迭代周期只有几星期甚至几天时，连假装的时间也没有。
试着讲一个故事，而不是写下细节。纸质的故事卡片、电子的跟踪系统以及 Backlog 管理工具都只是一个提醒，提醒“这里有一场关于某个故事的对话”。将所有的业务持份者和交付团队的成员纳入到一场讨论从，从各个不同的角度审视用户故事、探索各种可能得选项，这才是解锁用户故事方法所有好处的方法。
如果某种监管政策要求经过正式批准流程和书面签署的需求文档，那么可以尝试将签署过程推迟到每个用户故事的讨论环节之后，在带有示例的规格书（Specifications with examples）上签字，这一规格书是故事细化和分析讨论的成果。
2. 不要纠结于用户故事的格式
用户故事只是一次对话的提示，只要保证内容是正确的、并且足够开启一场讨论就可以了，不用纠结于格式和模板。
用户故事需要讲清楚“谁”、“为什么”需要它，“As a…, I want…, So that”这样的模板很好，但也不是必须采用这样的句式。在讨论中可以尝试不同的说法，这有助于激发团队的创造性。
捕捉用户借助软件能够回答的问题常常能获得好的用户故事，比如“每一笔销售平均花费的时间是多长？”，这样的问题能够满足用户故事的两个很重要的目标：让实施团队可以安排开发计划，以及激发一场良好的讨论。
如果只在卡片上写下简短的摘要，那么要避免在没有上下文的情况下描述一个解决方案。例如“在被阻塞的项目中有多少潜在的现金？”是一个好的摘要，而“现金报表”则不是。
用户故事要关注对问题的陈述、从用户角度看待事物，而不是软件实现。
3. 描述（用户）行为的变化
用户故事的“独立”和“有价值”这两个特性与“小（到能在一个迭代完成）”这个特性难于调和。（用户故事的INVEST）软件的价值常常是不明确和难以理解的，而任务的大小则是交付团队可以控制的，所以很多团队最后只是根据任务的大小来“凑”满一个迭代周期，而忽略了业务价值。这导致团队交付的内容和业务部门关心的功能之间的断层。
很多开发团队总是假定用户要求的一定是有价值的，而不会去质疑这一点。Robert Brinkerhoff 在“Systems Thingking in Human Resource Development”中指出有价值的创意一定会对某人或某些人的工作方式产生可观测的改变。这个原则对于判断用户故事的价值具有非常大的帮助。将这个原则运用到软件开发过程中意味着不经过要描述用户的行为，还要描述用户行为的改变。
搞清楚用户期待的行为变化有助于交付团队提议更好的解决方案，也使得团队可以从业务的角度评估交付的功能是否成功。
可测量的行为改变使得用户故事更容易被分解。可以从不同的变化维度或者变化幅度将一个故事分解成多个子故事安排开发计划。
4. 描述系统的变化
在确定了一个用户故事的解决方案之后，我们需要明确在这个故事实现前后系统功能和业务规则会发生怎样的变化。不是说要详细规定实现细节，而是要说明可观测的系统输出的变化。在修改已有的系统功能时这一点尤其重要。但即使这个故事是要增加新的特性，那么也不可避免地会改变系统的行为。
简短的故事描述也留下很多歧义。即使面对面的讨论也可能无法使所有人明了某个用户故事实现后的所有影响。这时就需要说明系统行为的变化。而且清楚知道系统行为变化的大小也有助于评估用户故事的实现复杂性。