这个标题让人高兴，因为毕竟有了进步。
这次的会议仍然还是两个小时，与会人员都是按时参加。由于这次上午还安排了别的事情，所以不得不经常出入会议室，有些打乱了大家的思绪。
会议开始后，Product Owner提议先把前两个Sprint中没有完成的Story拿进来，要在这次的Sprint中完成。同时，由于前两个Sprint的进度并没有预期的快，所以这个Sprint的任务比较艰巨。当然比较有利的一点是：已经有了前两个Sprint打不错的基础。Product Owner拿出来Project最重量级的一个Story，并且是必须要完成的。S很诧异，感觉压力很大，Product Owner当即表示，其中有些工作他可以分担一部分。接着，Product Owner又拿出了两个Story，这两个相对来说比较轻量，并且和前几个都是相辅相成的。
Product Owner大致解释过这次要做的几个Story之后，和S确定了一下这个Sprint他可以投入的工作时间。其实这个无意间提醒了S和W估算工作量时，一定要考虑实际可以工作的时间。不要让自己背负太重的压力。
接下来S和W开始就Story的相关细节向Product Owner提问。由于上次失败的教训，S首先就问道了如何Demo的问题。Product Owner说：“你可以先拿出一个方案，然后和我讨论。当然也可以，我直接说一个。看你更倾向于哪种？”S想了一会儿说：“你看这样行吗？提供一组数据在然后运行一下程序，在Console中查看结果。”Product Owner爽快地答道：“没问题。”如果Product Owner完全不懂技术，这种Demo应该是没有意义的。沉默了一会儿，S好像想起了什么，问Product Owner：“演示时的数据，是我在程序里写死吗？”Product Owner：“当然不能了，要不然我怎么知道你到底是不是实现这个功能呢？我至少要验证我每次输入不同的数据，程序会给我不同的结果。如果我输入了超出规定范围的数据，那么程序应该会给出相应的提示。”我说：“Product Owner这句话中包含了比较中的Acceptance的信息，你们是否考虑写在Story的背面呢？”“呵呵，对，吸取教训”S和W异口同声道。于是原来只有一句话的Story Card渐渐地丰满起来，写满了细节。
接下来自然划分任务、估算工作量，不知不觉两个小时过去。S好像还有些意犹未尽，Time Boxed的Scum不允许拖延，会议按时结束。
大家感概到：“看来两个小时并不长，以前都没有认识到计划会议的重要性，对细节讨论的太少，想当然的太多了，这次就不一样了。心里有底多了。”
良好的开始也就意味着成功了一半，当然剩下的一半就需要需要努力工作了！！加油！
