什么是User Story

Sprint Backlog 里的项目我们通常用User Story 来描述，User Story 是从用户角度对系统的某个功能模块所作的简短描述。一个User Story 描述了项目中的一个小功能，以及这个功能完成之后将会产生什么效果，或者说能为客户创造什么价值。
User Story 要由Stakeholder 来编写。User Story 的形式很简单，人们可以很容易地掌握编写User Story 的方法。这样就可以保证是由与项目相关的领域专家们来写User Story，而不是开发人员。
我们通常把User Story 写在一张小卡片上，同时在卡片上标明它的优先级和预计完成时间，以便开发人员根据任务的优先级来制定Sprint Backlog。而且，Stakeholder可以随时更改一个Story 的优先级，那么此时开发人员就应该相应地调整Story 的开发次序。
一个User Story 的大小和复杂度应该以能在一个Sprint 中开发完毕为宜。如果UserStory 太大，可能会导致对它的开发横跨几个Sprint，这种情况是需要避免的，此时就应该将这个User Story 分解。User Story 有一个通用的公式格式，大家可以套用一下试试，很简单。作为<某个角色>，我可以<做什么>，以完成<什么目的>。例如：作为一个病人，我可以预约一个医生，让他给我看病。这种表达方式清晰明了，提供了足够的信息以供测试。更详细的实现细节会在要完成这个User Story 的Sprint 开始之前确定下来，并补充到Sprint Backlog 中去。这是一种把客户需求分解为可测试的且有优先级的任务的有效方式。为了能及时、高效地完成每个Story，Scrum 团队会把每个Story 分解成若干个Task。每个Task 都是可以在明确的时间内完成的，而且时间是以小时为计量单位的。
特别提示：每个Task 的时间最好不要超过8 小时，就是要保证在1 个工作日内完
成，如果做计划时发现有些Task 的时间超过了8 小时，就说明Task 的划分有问题，需
要特别注意。