Run Mini Demo in the Sprint

在Scrum的5个正式的会议中，我们都知道有一个Sprint Review meeting，此会议的目的是团队给相关的PO 和干系人演示完成的用户故事，在会议中PO 确认这个冲刺所交付的用户故事，针对交付的用户故事可以提出意见，规划release plan，预算，介绍接下来冲刺的重点内容，评估接下来的人员情况，最后可以有一个小小的庆祝🎉仪式。

往往一个冲刺的周期是1-4周，那么PO只能在最后的Sprint Review meeting 上才能看到真正可工作的软件，这时候其实对PO来说，已经很晚了。为了解决这种问题，我们可以在冲刺中增加这种Mini Demo 的环节。在Mini Demo中更早的发现业务需求问题，更早的验收用户故事级别的需求，及时的纠正。这也符合测试左移的原则。

User Story Mini Demo 的定义

在一个冲刺周期内，每一个独立的用户故事开发完成后，我们可以邀请PO进行小组的Mini Demo演示。

注意以下几点：

- 不需要全员演示，可以是与这个用户故事直接相关的研发人员，测试人员，需求人员。

- PO 要严格按照验收条件（AC），一条一条的进行验证。如果团队刚开始敏捷实践，这步是必须的。

- PO 反馈的要求或者需求变更，研发根据原始的需求(AC) 进行对比，评估改动工作量和影响。研发团队决定是否在当前冲刺修改，或者创建新的用户故事，放到下一个冲刺中。

- 时长应该不超过30分钟。

有了User Story Mini Demo，我们还需要 Sprint Demo Meeting 么？

还是需要的，因为Mini Demo 更多是Scrum 团队内部人员的Demo，并不包括外部干系人。所以Sprint Demo Meeting 是很好展示当前冲刺交付的用户故事。

我们还需要SIT 进行测试么？

如果在用户故事这个级别，如果研发人员已经按照验收条件（AC）进行了测试，或者单元测试覆盖(Unit Testing），您觉得在用户故事级别我们还需要 SIT做测试么？

SIT 人员其实可以更关注整个Sprint中的：

自动化测试开发：如果团队成熟这应该是测试人员的主要任务

冲刺中测试策略的制定：帮助团队制定最优的测试策略，例如兼容性测试，回归测试用例裁剪的策略制定测试计划：如果SIT参与用户故事级别的测试，SIT需要知道哪个先开始，用户故事之间相互依赖等信息，安排好测试人员

辅导Scrum团队成员编写高效的测试用例：培养团队成员的测试思维，帮助团队尽早的完善用户故事中的验收标准（AC），将测试用例前移。

真正的系统集成测试（外部系统与本系统的集成测试）：与外部系统联系人的协调，沟通

Mini Demo 的形式在Sprint中是必须的么？

Mini Demo的目的是帮助scrum 团队更早的与PO进行沟通和确认，减少Sprint Review meeting中所用的时间，及早的发现问题。如果取消Mini Demo，我们就会纠结在Sprint Review meeting中，我们是否需要将每个用户故事中的验收标准（AC）执行一遍？还是录个Demo视频？