用户故事体现了用户需求以及产品的商业价值，同时定义了一系列Acceptance Criteria(AC)。只有团队完成的工作符合这一系列的AC时， 才算真正完成了这个用户故事。一个用户故事通常包括三个要素：

角色：谁要使用这个功能。

活动：需要完成什么样的功能。

商业价值：为什么需要这个功能，这个功能带来什么价值。

用户故事可以有不同的展现形式，以下是其中一种：作为一个<某种类型的用户角色>，我要<达成某些目的>，只有这样我才能够获取<商业价值>。

所以用户故事一旦被确定，那么它所要实现的功能、需求范围、所需工作量也就随之确认了。之后开发人员所要做的就是根据这个用户故事的内容进行开发，只有当所有AC被覆盖到，测试人员完成测试，发现所有功能是可测试的、可运行的，这个用户故事才算完成了。

估算和迭代计划

估算(Estimation)：团队在动手开发一个用户故事功能之前，应当对实现这个用户故事所需要的工作量有清晰的认识。如Martin Fowler所说，"Estimation is valuable when helps you make a significant decision"。只有当团队对达成一个目标的工作量以及完成它之后的“收益”有明确的认知， 才能做出明智的决定。

当团队在为工作排定优先级、制定迭代计划时，业务分析师需要知道每个用户故事的成本，atv，团队成员需要知道每个用户故事的价值。有很多种估算用户故事工作量的方法，其中一种就是把完成这个用户故事所需要的点数（根据用户故事的复杂度估算）写到对应的故事卡上。估算可以帮助团队以不同的方式，对实现即将开始的用户故事、未来的架构方向和代码库的设计，有更好的理解。一个迭代能完成多少个点数是能估算出来的。也可以使用一些工具统计出过去每个迭代所完成的点数，比如燃尽图。

只要整个团队共同协作，估算本身也可以变成一种很有意义的活动。它有助于团队增进理解，并保证团队每个人都对要交付的需求范围和价值达成共识。让评估变得更有趣的是，通常不采用简单连续的数列，比如1，2，3，4，5等——而是采用一种近似菲波拉契数列的形式，像1，2，3，5，8，13等（正如《达芬奇密码》里面看到的），这样当数字越大、相邻数之间的间隔就越大，使得团队更容易区分哪个故事更小、哪个更大。

在做迭代计划(Iteration Planning)时，团队需要从客户价值维度和技术风险的角度来排定优先级。下图中是常用的工具之一——需求优先级矩阵。

迭代会议和功能演示

敏捷宣言里面有一条：客户协作优于合同谈判。在敏捷团队中有一个角色叫做业务分析师(BA)，其核心职责是确保业务需求的清晰和透明，保证开发团队对业务有足够的理解，并将这些待完成的用户故事按照优先级排列出来，以任务卡的形式来驱动团队的开发。

迭代会议(IPM)通常发生在每个迭代的第一天，团队成员一起制定迭代计划。这个会议由BA主持，大家一起同步几个方面的内容：

下一个迭代的用户故事

对下一个迭代的期望和计划

风险的评估和总结

不同的人对需求有着不同的理解，所有团队成员都要对用户故事所有相关内容、所要实现的功能、满足哪些条件用户故事才算完成达成一致。迭代会议的主要产出是下一个迭代中需要完成的用户故事，这些用户故事即为下一个迭代所要完成的主要目标。

功能演示(Showcase)是敏捷开发流程中的又一个实践，通常发生在每个迭代的最后一天，目的是演示可工作的软件。团队把一个迭代中开发好的功能给相关人员演示，并收集反馈，以便在下一个迭代中可以对变化作出快速响应。

站会和用户故事开卡

简单地说，站会(Standup)是团队在一起快速地开一个会(通常在物理墙前)，成员逐个更新自己的状态。更新包含以下几个方面：

昨天完成的工作；

今天计划做的工作；

面临什么阻碍，需要什么帮助；

自己手头用户故事的进展，是否存在技术风险。

既然是快速的会议，站会的时间就不宜过长，10分钟左右为佳。建议团队成员站着开会，因为研究表明，当人们坐着开会的时候，会议的时间会被无形中拉长。

这里有一些实践原则：

团队成员都要参加站会，轮流主持，谁迟到了都不等——仪式感很重要。