一个用户故事的样例（极限编程）

用户故事是从用户的角度对系统功能的描述，通过与用户一起探讨而得出，事实上XP的实践应由用户亲手撰写用户故事，但对很多用户来说并不容易，所以很多的实践过程中是开发人员和用户一起撰写。

开发人员依照用户故事中的描述估测完成每个任务需要的时间，并从项目经理处认领自己负责的任务，通常鼓励开发人员每次认领不同类型的任务，以提升对整个项目的认识及对不同类型技术的掌握。此处估测的时间在项目初期可能和实际完成时间有较大差距，但通过一段时间的实施之后，故测的时间也能八九不离十了。

领得自己负责的任务后，开发人员寻找结队伙伴，并开始实施过程。两者在边讨论边设计的过程中产生软件设计，并付诸测试和代码，此处产生的成果只有单元测试和代码而已，至于设计可以全部置于草稿纸上，一旦测试和代码完成便没有任何意义。若讨论过程中有明显的分歧，应该以任务负责人的想法为先。应该注意的是，这里为每个任务都分配了“负责人”，但XP的思想是整个开发团队对代码负责，而不是个人，因为事实上即使是单个任务也是由多个开发人员共同完成的。XP鼓励要经常更换结队伙伴，即使只是在一个任务中。

以下是一个用户故事的样例：

故事2运行处理退款请求故事（优先级：高  技术风险：低）
估算：开发时间 2周
2.1 获得某时间段银行的退款明细          0.5天
2.2 分页显示某时间段银行的退款明细列表，提供选择退款记录    2.5天
2.3 运行处理退款              2天
2.4 （约束）2.3可以补充退款信息卡号、姓名信息，如果要求输入卡号要输入2遍复核
2.5 （约束）2.4输入卡号提供3个4位输入第4个不限位数的分割输入，利于校对
2.6 （约束）2.4卡号栏目后面要留输入标注（本）（异）来区分本地卡和异地卡的空间
2.7 （约束）2.3可以选择部分或全部明细进行退款处理
2.8 （约束）2.3处理后退款明细记录状态要变更为运行已处理状态，并置运行处理日期
2.9 （约束）2.3按确认后要一个确认对话框，防止误操作
2.10 可以按条件获得退款明细列表          1天
2.11 （约束）2.10条件可以为：银行&退款处理状态&退款请求日期段
2.12 （约束）2.10条件可以为：商户&退款处理状态&退款请求日期段
2.13 （约束）不需要查询还在申请状态的退款
2.14 分页显示按条件获得运行已处理的退款明细列表      1.5天
2.15 （约束）2.14表头里须含查询条件信息及总笔数与金额信息
2.16 可以下载退款明细列表           2.5天
2.17 （约束）2.16数据组织成execl表格格式
2.18 （约束）2.16表可以按每个支付网关生成一份
2.19 （约束）2.16表可以按每个商户生成一份
2.20 （约束）2.16表中，部分支付网关除基本栏目外，一些栏目可以配置打印与否。
2.21 可以把运行已经处理过的退款交易回退给运行部门重新处理。
2.22 （约束）2.21可回退的退款交易必需是还没有被财务退过款的。