短之又短的用户故事

Scrum团队通常喜欢使用用户故事来表示待办事列表项目。但是很不幸,一个用户故事中最重要的一环通常会被渐渐忘掉,那就是用户故事应该保持简短,慢慢地用户故事失去了它的本质和效力。

用户故事现在通常以“作为一个…我希望能…”的形式来描述。用户故事的编写者,应该马上利用约束列表或者自动化验收测试的形式来记录下该用户故事的验收标准。很多人觉得如果团队以外的成员(例如,高级经理或者股东)不能在没有别的文档的帮助下明白用户故事的目的,那么这个用户故事的编写就是失败的。

一个理想的用户故事的描述应该是一个简要的描述——Robert Martin把它叫做“助记令牌”。
Read more

如何进行有效的backlog梳理

当我作为一名敏捷教练进入组织的时候,Scrum带来的常见烦恼之一就是Sprint计划会议。“这些会议简直太长了!”我的客户抱怨着。对此,一个简单但既能缩短计划会议时长,又能提高效率的方法,就是定期使用产品需求梳理会议。
有时候也叫做“故事会议”,会议的目的就是改进产品的backlog。定义之所以有些模糊,是因为会议本身就是驳杂多样的。一个需求梳理会议可以用来:
Read more

将用户故事分解为任务

将用户故事分解为任务没有什么捷径,许多的开发者在他们的工作当中也一直在做类似的事情-将需求分解为任务。由于放到Sprint当中的用户故事的规模已经比较小了,所以有些人认为已经没有必要在进行分解。那么为何还要对用户故事进行任务的分解呢?

尽管用户故事的确可以小到作为工作的单位,但是将他分解为更小的任务,通常跟符合项目的需要,主要表现在如下三个方面:
Read more

什么是用户故事(User Story)?

什么是用户故事?

用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素:

1.     角色:谁要使用这个功能。

2.     活动:需要完成什么样的功能。

3.     商业价值:为什么需要这个功能,这个功能带来什么样的价值。

用户故事通常按照如下的格式来表达:
Read more

用户故事的划分

在Release计划会议和Sprint计划会议中,划分用户故事是一个很重要的活动。但是很多时候,团队成员并不清楚为什么需要小的用户故事,应该怎样划分。常常为这些问题争论不休,因此我在这里做一个回答。

为什么用户故事越小越好

  • 缩短完成用户故事的时间

很多人想当然的认为用户故事大小跟完成的时间是成正比(线性的)。但是事实并不是这样。有研究表明随着用户故事规模的增长,完成它需要的时间会呈非线性的增长。参见“Scale Lean & Agile Development”里面的截图。两倍大小的用户故事需要花五倍的时间来完成。为什么?因为随着其粒度的增大,不确定性(由于缺陷、人的因素,外部依赖等因素)会急剧提高。
Read more