確定人員，保持小而靈活的團隊。
先行開發確定需求，不浪費所有人的時間，實際是把整體的開發時間都提前了。
相對於瀑布流，團隊所有成員一次把專案的所有細節都研究詳細了，再開始開發工作，這裡面有個弊端是，我們發現每次需求過來的時候，通常情況下大部分的邏輯設計都還是相對清晰的，而卡出的地方往往佔少部分，完全沒必要把所有的人都拉到一起確認，開會是個很耗時間的東西，一兩天很容易就廢掉了。
這種情況下，其實那些“大部分清晰的需求”是可以先行開始，只需要專案負責人或者Scurm master來和產品確認有問題的部分，然後轉達給其他成員，保持團隊資訊透明。
分析到什麼程度？
流程可通，預留時間給團隊成員，和產品確認問題，最多兩天時間。
只要成員可以根據需求順利的估算時間，而且估算時間本身不太需求特別細節的追究，別把實現方式放到估算中討論，把問題放到領取這個故事的人，減少在多數人蔘加會議情況下的時間。而且時間估算本身就是預估，是一個參考值，在總體的時間上達到一個平均值就可以。
雙向溝通，相互講解
首先產品給研發講解需求，然後研發拿到需求詳細分析，再給產品講一遍，保證開發前理解無偏差。
確定本次迭代目標
這點非常重要，必須讓大家都非常明確本次目標，開發範圍，要做的事情。
Scrum Master
Scrum Master一定要把自己從程式碼中解放出來，不要抱著領故事寫程式碼，推動團隊順利進行更重要，團隊建設和完善，需要更多時間思考。