确定人员，保持小而灵活的团队。
先行开发确定需求，不浪费所有人的时间，实际是把整体的开发时间都提前了。
相对于瀑布流，团队所有成员一次把项目的所有细节都研究详细了，再开始开发工作，这里面有个弊端是，我们发现每次需求过来的时候，通常情况下大部分的逻辑设计都还是相对清晰的，而卡出的地方往往占少部分，完全没必要把所有的人都拉到一起确认，开会是个很耗时间的东西，一两天很容易就废掉了。
这种情况下，其实那些“大部分清晰的需求”是可以先行开始，只需要项目负责人或者Scurm master来和产品确认有问题的部分，然后转达给其他成员，保持团队信息透明。
分析到什么程度？
流程可通，预留时间给团队成员，和产品确认问题，最多两天时间。
只要成员可以根据需求顺利的估算时间，而且估算时间本身不太需求特别细节的追究，别把实现方式放到估算中讨论，把问题放到领取这个故事的人，减少在多数人参加会议情况下的时间。而且时间估算本身就是预估，是一个参考值，在总体的时间上达到一个平均值就可以。
双向沟通，相互讲解
首先产品给研发讲解需求，然后研发拿到需求详细分析，再给产品讲一遍，保证开发前理解无偏差。
确定本次迭代目标
这点非常重要，必须让大家都非常明确本次目标，开发范围，要做的事情。
Scrum Master
Scrum Master一定要把自己从代码中解放出来，不要抱着领故事写代码，推动团队顺利进行更重要，团队建设和完善，需要更多时间思考。