敏捷开发对需求规划的要求是很高的，首先需求是打散的，一个大的项目需求会拆分成很多小的功能完整的需求，以便排定优先级去逐个实现，敏捷开发提升了开发效率，但是对需求规划的要求更高了，就是对产品的需求规划能力提出了更高的要求，必须有清晰的思路，很强的需求规划能力才行，这样才能保证敏捷开发可以按照既定的设想去一步一步实现产品的设计。
敏捷开发是通过“用户故事”这个东东来实现传统软件开发所说的需求的。
一、什么是用户故事？
用户故事就是定义用户所需功能的文字描述，简单说就是用户的需求。一个好的用户故事包括三个要素：
1. 角色：谁要使用这个功能。
2. 活动：需要完成什么样的功能。
3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。
二、用户故事的描述
建议采用两种方式来进行用户故事的描述，用户可以任选一种：
- 作为<用户角色>，我需要<功能>，以实现<业务价值>
- 为实现<业务价值>，作为<用户角色>，我需要<功能>
举例：
作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”
注意事项：
用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。
三、用户故事与任务、测试等对象的关联
每个用户故事与多个开发任务、变更、缺陷（Bug）、测试用例和测试历史相关联。
1、与任务的关联
用户故事通过任务来实现。 实际开发工作比用户故事更琐碎。 实际上，每个故事都是多项任务的集合。把故事分解成多个任务，安排到人，完成了所有的任务，就意味着实现了用户故事。
2、与变更的关联
敏捷开发就是鼓励大家“拥抱变化”，每次用户故事变更都做记录，与相应的用户故事相关联，这样方便整个团队了解用户故事的来龙去脉，减少重复劳动。
3、与测试用例的关联
每个用户故事开发完成需要进行测试，测试工程师应当为用户故事编写一个或多个测试用例。
4、与测试历史的关联
记录用户故事经历了哪些测试，测试的结果和处理情况如何。
5、与缺陷（Bug）的关联
记录用户故事发生的缺陷，查看缺陷的处理情况。
敏捷开发确实是好东东，但是国内由于长期受到传统软件开发思想的熏陶，中毒太深，大多数人仍然用模块化的思维方式来考量需求，始终不能用“价值”来考量需求。
这篇就先写到这里，下一篇继续用户故事的验收标准和用户故事编写原则的撰写，初学乍练欢迎大家前来拍砖。