需求拆分

将大块的业务功能需求拆分成多个小的业务功能需求，再对这些小需求进行评估和优先级排序分批进行迭代交付，可以让团队能够尽早得到可运行的系统，并让业务人员能够看到业务的功能进展，以便与工程师沟通，提前发现需求理解不一致等问题。同时，还可以灵活应对临时的需求变更，响应市场的快速变化。

需求的来源

最开始的需求列表是根据业务人员提出的需求形成的，但随着讨论的深入，我们还会发现业务人员没有意识到的潜在需求。在进入交付期之前，需求来源由以下 3 部分构成：
1、业务人员提出的业务功能需求，这些业务需求构成了整个产品版本的基础需求
2、为了保障业务需求的实现与运行而必须满足的非业务功能需求，如性能需求
3、符合安全合规性而产生的安全开发需求

进入交付期之后，需求来源包括 7 个部分：
1、从原始需求列表中选出的待实现需求
2、在需求细化过程中发现的新需求
3、已知且需要修复的线上生产系统缺陷
4、线上技术运营需求
5、前期预研需求，它是指团队目前尚不具备能力，但为了实现某一业务需求而做的准备工作
6、技术债需求，指因早期业务进度压力而积累的技术债改进需求
7、辅助测试需求，为了便于进行需求验收，需要开发的测试辅助工具

INVEST 原则

INVEST 原则是用于检验 story 是否拆分得当的 6 个原则：
Idependent(独立)：一个用户故事应该是独立低耦合的。通常可以通过组合用户故事或者分割用户故事来减少依赖性
Negotiable(便于沟通)：一个用户故事是便于沟通的。一个故事的卡片是包含故事详情的简短描述，这些详情是通过讨论阶段来完成的
Valuable(有价值)：每个故事必须对客户具有价值（无论是用户还是购买方）
Estimable(可估算)：开发者需要去估计一个用户故事的工作量以便确定优先级并对故事进行规划。让开发者难以估算的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
Small(短小)：用户故事必须足够小，尽可能在一个迭代内完成（建议少于 3 个工作日），且多个用户故事时间的工作量差异不宜过大
Testable(可验证)：用户故事必须是可以被验证的
在现实工作中，可能存在一些非常复杂的用户需求，很难同时满足这 6 个原则，那么至少需要满足可估算、规模小且可验证原则。