你們是否有Product Owner？是不是有人可以代表客戶與你們一起工作？
當團隊在決定應該構建什麼樣的產品時，這個人就是他們要詢問的對象，這個人代表着客戶的需求與利益。
如果有Product Owner的話，他們是否擁有一個待開發功能的Product Backlog？此Backlog是否根據業務價值排定了優先級？是否已經估算過開發這些功能需要多少時間？
這是一個Product Owner爲一次版本發佈構建路線圖所需要的依據。
團隊在開發過程中，有沒有使用 Burndown圖，來展示當前迭代中隨着時間的推進，剩餘工作量的變化，以跟蹤進度？並且能否基於Burndown圖來推算團隊的速度？
首先，Product Owner可以根據它來構建發佈規劃；同時團隊可以根據它來真正改進流程。只有知道自己的速度如何，這有助於一個團隊進行更好的估算，同時幫助他們在繼續後續工作時提升速度。
Scrum團隊依賴自組織的過程，這就意味着團隊負責挑選工作、職責分配，並要找出最快交付工作的途徑。所以，Nokia的最後一條規則是：在迭代中，項目經理不能干涉團隊工作，因爲這會停止自組織的過程，並且得到解決方案的過程將不再是最優化的了。
爲什麼非得要專門的Product Owner？PM代替不可以嗎？
首先，產品Backlog是Scrum的核心，從根本上說，它是一個需求或故事或特性組成的列表，並且按照重要性進行了排序，一定是客戶想要的東西，並且用客戶的語言進行描述。產品的Backlog應該僅僅由那些產品相關的較大的任務（ticket）組成，有關在產品開發中完成某項工作時候涉及的東西，太細了就不適合。
其次，在維護產品Backlog的時候，Product Owner（就是那個能替最終客戶發言的人）必須參加，由他排列優先級。Product Owner必須是離客戶最近的人，你作爲研發項目管理人員，不可能是離客戶最近的人。如果沒有這個角色，你們怎麼知道哪個重要哪個不重要？和Product所有人交流，你們纔可以做出來一個有優先順序的列表，把最重要的功能放在列表的前面。
那這個Backlog條目除了優先級外，還有其他什麼要求？
每一個條目應該有估計完成時間，這個並不需要很準確。我們只需要有一個大概的估算即可，這樣才能夠決定把多少工作放到一個Sprint裏。
另外，在你開sprint規劃會議之前，你的產品Backlog應該保持一種合適的格式。你可以是把它們都放在一個Excel中，也可以是一個Word文檔，或者是某種Scrum工具中……採用哪種形式都可以，只要你們自己覺得方便就行。
Sprint計劃會議除了你的團隊成員和Product Owner外，還可以邀請更多的人蔘加。
在Scrum框架下，沒有“個人”的概念，Scrum依靠的是團隊的力量。儘管Scrum Master在這個框架下的作用很重要，但這個人不是獨裁者。做Sprint計劃時，一定要讓整個團隊參加。
大家一起做計劃，豈不是很亂？
首先，你們要先定下來Sprint的目標，即作爲一個團隊，你們要完成什麼，然後再決定完成多少。
我們當前沒有任何歷史參考數據，怎麼知道完成多少呢？
事先計算出在一個Sprint內，團隊的可能工作時間。譬如，在未來三週內，一個5人小組，每人每週工作40小時，那麼總的工作時間=5×40×3=600小時。
要將總的工作時間扣除任何預期的非工作時間。譬如，有一個人要休一個禮拜的年假，還有人要看牙，需要佔用3天，這樣算起來是600-5x8-3x8=536小時。
得把每天花在參加會議、談話、處理郵件、上網等時間都除去。
我們把它用百分比表示，5/8，那麼就是60%左右，然後用這個“負荷指標”（Load Factor）乘以總的工作時間小時數，你就得到了536×小時。
然後從產品Backlog中，按照優先級從高到低，選擇出你們認爲能在322小時內完成的條目，作爲你們當前Sprint的Backlog。注意：選擇的Sprint Backlog Item一定要強內聚、鬆耦合，這樣你們才能不受或者少受外界的干擾，目標明確。
那個“負荷指標” 60%應該是變動吧？我們剛做一個項目，跟項目做了一段時間相比，肯定是不一樣的。再譬如我有新員工加入時，他的效率肯定是要比老員工低的。
你可以利用它把Sprint計劃得很準確。當你遇到低的“負荷指標”時，要試着找出根本原因，這會使你門的Sprint更有效率。
對於每個細化後的任務，都需要一個非常明確“完成”（Done）的定義。這一點非常重要，必須保證每一個人的理解是正確的、一致的。
估算時，可以用“計劃撲克牌”來估算完成時間。
做Sprint任務細化時，一個最佳實踐就是把每個任務控制在2～16 小時之間。任務太細，會涉及更多的微觀管理，太粗，估算就會不準確。
下一步，就是讓大家自己認領任務，而不是指派！這一點非常關鍵
首先，每個人認領任務後，實際上就是對整個團隊有了一個承諾，更能保證按計劃完成。其次，讓每個人選擇自己願意做的事情，這樣纔會更有主動性，畢竟“做自己有興趣的事情，纔會真的做好”。這樣，不僅滿足了個人發展的需要，還可以達到快速的知識共享、團隊技能的整體提高。
此外，跟任何其他會議一樣，對於跨度一天的計劃會議，確定好會議日程非常重要。因爲Sprint計劃會議一定要基於Time-Boxed，在規定的時間內，一定要結束，就像一個Sprint一樣，同樣要有緊迫感。
還有，Sprint計劃會議必須在一個完整天內開完。
Sprint計劃會議開始的那一天，也就是Sprint開始的一天。如果Sprint計劃會議要跨越兩天，可不是什麼好玩兒的事情，你的Burndown Chart就會像我們的這樣很難看。你會看到Sprint才一開始，似乎我們的工作量只有150，怎麼第二天時工作量就快到了190，出現了一個凸起。如果不瞭解內情的話，一定還以爲Sprint出了問題呢。而實際上是因爲我們曾經在前一天的下午開了4小時，第二天上午又開了3小時，對任務進行細化，結果任務估算增加。
採用Delphi方法進行任務工作量的估算。當進行任務細化的時候，每個人的估算是不一樣的，如果最高估算值跟最低估算值相差一半以上，二者就要溝通一下，看看爲什麼二者的理解相差這麼多。溝通明白後，再重新估算。即使這樣，還是會有分歧的，此時採用Delphi估算方法，簡單講就是進行一次加權平均。
爲了提高任務細化的效率，可以將團隊分成兩個小組分別進行。
把Team分成兩個小組，分別對任務進行細化。細化時，不再用投影儀，而是把Sprint Backlog中的內容按大塊張貼在牆上，大家站在牆前，拿着記事帖直接進行細化和估算。當兩個小組都進行完後，互相檢查對方對任務的細化，解決爭議，澄清模糊的地方。這樣一來，就把大家的積極性調動起來，參與程度非常高，效率也高。
產品負責人（Product Owner）一定要參加。實在不能參加的話，也要指定一個人授權代理。否則，就不要開Sprint計劃會議。
最後一點，雖然我們採用了Scrum，但即使不再採用Gatt圖，但是傳統的Risk/Dependency分析還是不要丟棄。在Sprint計劃會議結束前，進行Risk/Dependency的分析，還是會幫助我們發現一些問題的，然後再稍微重新調整任務的優先級，更能保證Sprint的成功。
Scrum依靠的是經驗管理，所以他沒有定義出很細的工程實踐。這樣才能很好地跟組織原來的工程實踐融合起來，譬如跟CMM、ISO 9000、RUP，甚至XP等都能很好地工作在一起。因爲Scrum主要是想解決項目管理和組織實踐範疇的東西，更多的是關注在敏捷團隊建設上，它的終極目標就是自我管理自我組織的高效團隊。作爲一個敏捷框架，具體的編程實踐，可以靠XP去補充。但我還是建議你們，最初先努力適應這個框架，待成熟後再考慮引入其他敏捷實踐。