http://blog.csdn.net/chengyb74/article/details/4762247
对于敏捷开发来说，User Story是开发的基础，它不同于传统的瀑布式开发方式，而是把原本需求拆成最小粒度的Story，以方便拆分Task，估计开发时间，领取开发任务。
优点和好处
- Being very short. They represent small chunks of business value that can be implemented in a period of days to weeks.
- Allowing developer and client to discuss requirements throughout the project lifetime
- Needing very little maintenance
- Only being considered at the time of use
- Maintaining a close customer contact
- Allow projects to be broken into small increments
- Suited to projects where the requirements are volatile or poorly understood. Iterations of discovery drive the refinement process.
- May be easier to estimate development effort
User Story模板
User Story可以遵循以下模板：As a <User Type> I want to <achieve goal> So that I can <get some value>
翻译成中文就是：作为一个<某种类型的用户>，我要<达成某些目的>，我这么做的原因是<开发的价值>。
User Story应遵循INVEST规则
- Independent 独立性，避免与其他Story的依赖性。
- Negotiable 可谈判性，Scrum中的story不是瀑布开始某事中的Contract, Stories不必太过详细，开发人员可以给出适当的建议。
- Valueable 有价值性， Story需要体现出对于用户的价值
- Estimable 可估计性，Story应可以估计出Task的开发时间。
- Sized Right 合理的尺寸， Stories应该尽量小，并且使得团队尽量在1个sprint(2 weeks)中完成。
- Testable 可测试性， User Story应该是可以测试的，最好有界面可以测试和自动化测试。每个任务都应有Junit Test.
一些经验：
- 永远不要在User Story中使用And和Or，因为这是些分支词就表示分支任务，把它们拆成两个Story.
- 数据整理：通常情况下1个sprint(2周一次迭代)可以做4～5个Story，极端大的Story不可大于1个sprint。
- 数据整理：通常情况下1个sprint(2周一次迭代)可以做50个左右的Task。
- User Story用于描述用户故事，不要包括任何的技术，框架等内容。Task可以包括框架，技术等内容。