怎样进行sprint演示

应该让团队中的每个成员都进行演示，即便他这次说的不好，那么下一次，他一定会提前准备好的，这对他主动地理解业务是很有帮助的。

一次做得不错的演示，即使看上去很一般，也会带来深远影响。
团队的成果得到认可。他们会感觉很好。
其他人可以了解你的团队在做些什么。
演示可以吸引相关干系人的注意，并得到重要反馈。
演示是（或者说应该是）一种社会活动，不同的团队可以在这里相互交流，讨论各自的工作。这很有意义。
做演示会迫使团队真正完成一些工作，进行发布（即使是只在测试环境中）。如果没有演示，我们就会总是得到些99%完成的工作。有了演示以后，也许我们完成的事情会变少，但它们是真正完成的。这（在我们的案例中）比得到一堆貌似完成的工作要好得多，而且后者还会污染下一个sprint。

Sprint演示检查列表
确保清晰阐述了sprint目标。如果在演示上有些人对产品一无所知，那就花上几分钟来进行描述。
不要花太多时间准备演示，尤其是不要做花里胡哨的演讲。把那些玩意儿扔一边去，集中精力演示可以实际工作的代码。
节奏要快，也就是说要把准备的精力放在保持演示的快节奏上，而不是让它看上去好看。
让演示关注于业务层次，不要管技术细节。注意力放在“我们做了什么”，而不是“我们怎么做的”。
可能的话，让观众自己试一下产品。
不要演示一大堆细碎的bug修复和微不足道的特性。你可以提到一些，但是不要演示，因为它们通常会花很长时间，而且会分散大家的注意力，让他们不能关注更加重要的故事。

如何处理“无法演示”的工作？

你做的工作过程或文档可以用来进行演示，因为那就是你的工作成果。