用户故事估算技巧
咨询师工作最大的好处之一，就是可以尝试很多种不同的想法，并可以把其中能够发挥作用的部分添加到自己最喜欢的流程之中。Jay Fields在实际工作中发现有些用户故事估算技巧十分好用，并对其进行详细介绍，写就本文。
InfoQ
十月 332,438名独立访问用户
赞助商链接
六折SD2C门票
InfoQ中文站读者
独享6折技术大会
门票，限量提供
OpenSolaris专题
下载OpenSolaris
尝试其超酷功能
参与本地用户组
活动，即刻访问
Sun科技日2008
11月19日于广州
11月21日于北京
与Sun一起分享国
际化开源软件平台
主题/标签专用视图
用户故事 Content on InfoQ
最新“用户故事”相关专题内容
“用户故事”相关新闻
以故事为焦点的站立会议
每日站立会议是被广泛接受的敏捷实践。团队成员在其中分享：上次站立会议后他们做了什么、在下次站立会议前要做什么、目前面临哪些障碍。Mike Cohn最近分析了站立会议的一些变种，这些会议将完成各个用户故事作为会议进程的一部分。.
用例还是用户故事？
用户故事 (User stories) 是否比用例 (Use Cases) 好呢？未必，还看看你在问谁。用户故事明显的好处在於鼓励对话和避免像编写重型需求文档的思维。但用户故事有没有缺点呢？
强调业务价值——用户故事的新格式
用户故事是捕获敏捷项目需求的常见形式，它还可以更注重业务价值一些。用户故事的传统形式为，“作为……我希望……”，换作以价值为中心的形式，就成了“为了……作为……我想……”。
Story points vs. Working hours
在Agile中，Story point和Working hours都是用于评估完成每个Story所要付出劳动，只不过前者使用相对尺寸来估计，后者则使用绝对时间。那么，在实际工作中，Story point和Working hours是否需要联系到一起？AgileChina讨论组中的讨论结果表明，多数人倾向于由团队自己做决定。
正确设定用户故事的大小
对于那些使用用户故事的人来说，敏捷过程中最困难的部分之一就是如何正确地编写用户故事——它们既可以推动你的工作，也可以让它步履维艰。最近，Pat Kua解答了一个核心问题：故事里应该放入多少细节？自然，其答案要“依赖于”你处在过程的哪一个阶段。
使用Product backlog是一种浪费行为吗？
规划要开发的特性是软件开发的一个重要组成部分。在Scrum过程中，期望开发但尚未实现的特性列表被称为backlog（或产品backlog）。这本应是轻量级的，但使用它是否仍然是一种浪费行为呢？