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