在明确故事内容时一定要向产品负责人如何进行演示,因为这很可能会决定你开发的方式,也间接的影响到了你对故事的时间估算。
例1:
团队和产品负责人都对sprint计划很满意,打算结束会议。这时Scrum master问了一个问题,“等一下,还有个‘添加用户’的故事没有估算时间呢,把它解决了吧!”几轮计划纸牌以后,团队意见达成一致,认为这个故事需要20个故事点;产品负责人却站了起来,说话因为生气也走了调:“什、什、什么?!”经过几分钟的激烈争吵,最后发现是团队错误理解了“增加用户”这个故事的范围,他们以为这表示“要有个漂亮的web界面来添加、删除、移除和查询用户”,但是产品负责人只是想“通过手写SQL操作数据库来添加用户”。他们重新进行评估,给它5个故事点,达成共识。
例 2:
团队和产品负责人都对sprint计划很满意,打算结束会议。这时Scrum master问了一个问题,“等一下,还有一个‘添加用户’的故事,它怎么演示呢?”一阵窃窃私语之后,某人站起来说,“呃,首先我们登录Web站点,然后……”产品负责人打断了他的话,“登录Web站点?!不不不,这个功能跟Web站点一点关系都没有,你给技术管理员提供个傻瓜都能用的SQL脚本就行。”
显然,例2更会节省时间并达到预期的效果。使用这种简单的描述,常常能够发现对于故事范围的最严重的误解。这种事发现的越早越好,不是么?