1.挑選一位產品負責人(productowner)。 這個人必須知道自己帶領的團隊需要做什麼、製造什麼產品以及取得什麼成果，必須全面考慮到風險與回報、什麼具有可行性、什麼能做以及他們對什麼富有熱情。
2.挑選乙個團隊(team)。真正做事的是誰？這個團隊必須能夠落實產品負責人的願景。團隊規模宜小不宜大，一般3~9人較為合適。
3.挑選 scrummaster。 scrum master為scrum過程負責，負責培訓團隊其他成員，確保scrum得到正確運用，幫助團隊消除一切障礙。
4.擬定產品待辦事項清單（productbacklog items），並確定優先順序。這個清單高屋建瓴地列出為了落實產品負責人的願景而需要完成的所有事項。在產品的整個研發過程中，這個清單一直存在，並有所演變，相當於產品研發的「路線圖」。無論在任何時間，要想知道乙個團隊要做的所有事項（按照優先順序排列），待辦事項清單都是唯一具有決定性的參考依據。待辦事項清單只有乙份，意味著產品負責人從頭到尾必須不斷地對優先順序加以調整。產品負責人應該與所有利益相關者和團隊進行協商，以確保產品待辦事項清單既能反映使用者的需求，又不會超出團隊的能力範圍。
5.改進和評估sprint待辦事項清單（sprintbacklog items）。讓負責實際開發工作的團隊對待辦事項做出評估，是乙個至關重要的環節。團隊應該審視每個事項，看看是否切實可行。但要完成這些事項，現有的資訊足夠嗎？該專案是否細分到了可以評估的程度？團隊是否具有了每個成員都能接受、用於評定乙個事項已完成的標準？乙個事項能否帶來顯著的價值？各個事項在完成後必須產生能夠用來展示的成果，如果這個成果能交付給客戶試用會更好。不要用所需小時數去評估，因為人們根本不擅長做出這麼精確的評估。要用相對難度去評估，比如，難度是小、中或大。更好的方式是採用斐波那契數列的數字（1，2，3，5，8，13，21……）。
6.sprint規劃會（sprintplan）。這是第一場scrum會議。團隊成員、scrum master以及產品負責人坐到一起，規劃sprint的內容。sprint週期一般是固定的，不超過乙個月，大部分是一至兩周。團隊要從待辦事項清單的頂端著手（即從最重要的事項著手），看看乙個sprint階段中能完成多少。如果團隊已經開展過好幾個sprint，那就記錄下每乙個sprint完成的事項的「點數」。這個數字相當於團隊的速度。scrum master與團隊成員應努力在每乙個sprint階段中提高這個數字。團隊成員和產品負責人也可以借助「點數」確保每個人都能了解待辦事項對於落實最終願景的作用。對於sprint目標，即在這一sprint階段完成哪些事項，所有人都應該形成共識。
scrum的基石之一在於，產品負責人告訴開發團隊他需要完成產品訂單中的哪些訂單項。開發團隊決定在下一次sprint中他們能夠承諾完成多少訂單項。在sprint的過程中，沒有人能夠變更sprint內容。團隊必須在sprint階段自主工作。
7.工作透明化（artifacttransparency）。在scrum中，最常見的做法是準備一塊白板，上面分成三欄：待辦事項、在辦事項、完成事項。把待辦事項寫到便箋紙上，隨著進度的推進，將相應的便箋紙轉移到其他欄目。
讓工作透明化的另乙個工具是燃盡圖。在這張圖中，乙個軸代表工作量，另乙個軸代表時間。每天，scrum master都會記錄待完成的剩餘點數，而後畫在燃盡圖上。理想情況下，該圖是一條向下的曲線，隨著剩餘工作的完成，「燃盡」至零。
8.每日站會（dailyscrum）。這是scrum的活力源泉。團隊每天在固定時間進行內部溝通，時間一般不超過15分鐘，且站立進行，scrum master向團隊成員提出下列問題：
（1）你昨天做了什麼去幫助團隊完成sprint？
（2）今天你打算做什麼來幫助團隊完成sprint？
（3）什麼因素阻礙了團隊的前進之路？
scrum master要問的問題就是這麼多！整個會議的內容就是這麼多！如果會議時間超過15分鐘，那就說明開會的方法存在問題。這樣做的意義在於讓整個團隊清楚地知道在這乙個sprint週期內各項任務的進展。所有任務都能按時完成嗎？有沒有機會幫助其他團隊成員克服障礙？團隊的任務都不是自上而下分派的，而是自主決定、自主完成的，也不需要向上司做詳細的匯報。scrum master負責消除團隊面臨的障礙。
9.sprint評審（sprintreview）。在sprint結束前，給產品負責人展示成果，也就是展示哪些事項可以挪到「完成事項」那一欄，並接受評價。這是一場公開的會議，任何人都可以是參與者，不僅僅包括產品負責人、scrum master及開發團隊，還包括利益相關者、管理人員與客戶。
團隊應該只展示那些符合「完成定義」的事項，也就是全部完成，不需要再做工作就能交付的成果。這個成果或許不是完整的產品，但至少是一項完整的、可以使用的功能。
10.sprint回顧（sprintretrospective）。團隊展示之前sprint中創造的成果，也就是展示已完成的事項，看看可以為顧客傳遞哪些價值，並徵求反饋意見，大家就會坐下來想想哪些事執行得很順利，哪些事應該做得更好，以及在下乙個sprint階段中可以做出什麼改善。那麼，如何發現流程中的哪個環節需要改善呢？
要讓這個sprint回顧過程有效，團隊需要相互信任。必須記住關鍵的一點，即大家不要從團隊中找乙個人當成責備的物件，而是要將注意力集中在流程上，認真分析以下幾個問題：為什麼會發生那件事？為什麼我們當時忽略了？怎樣才能加快工作進度？作為乙個團隊，大家要對自己的流程和結果負責，要集思廣益，共同尋求問題解決之道。這一點是至關重要的。
與此同時，團隊必須有勇氣把真正的障礙擺到檯面上來，這樣做是為了解決問題，而不是為了指責某個成員。團隊成員必須能認真**問題，並虛心接受他人反饋的意見和建議，以便尋求問題解決之道，而非只想著為自己辯解。
然後就進入了關鍵環節。團隊確定乙個最值得改善的地方，將其設定為下乙個sprint階段的首要任務，當然，改善的結果必須通過「驗收測試」。你如何證明自己成功地完成了改善？你需要用具體的、可操作的方式界定什麼是「成功」，這樣，在下乙個sprint回顧會議中才能很快判斷出是否已完成改善。
摘自：《用一半的時間做兩倍的事》（台版繁體）
《敏捷革命》（簡體中文）
實踐scrum隨筆
1.產品backlog 2.對於backlog的估算 3.燃盡圖 burndown 4.了解團隊的生產率 5.掌握scrum眾多的基礎實踐 scrum和極限程式設計 xp 都要求團隊在每一次迭代的結尾完成一些 可以交付的工作片段。迭代要短，有時間限制。將注意力集中於在短時間內交付可工作的 這就意味著...
Scrum 過程實踐小記
摘要 從去年10月份到現在，在我負責的專案中進行了一些scrum實踐的嘗試，做個小結。嚴格來說，不能算是真正的scrum實踐，但實踐敏捷的過程本身也是一種 敏捷方法 所以就算是 敏捷實踐之敏捷開發方法 scrum過程 吧。一 理論參考 scrum的實踐 該部分摘自網路 1.scrum 團隊 5 7個...
Scrum實踐 如何拆分Story
去年入職公司不久，就趕上了公司 敏捷 開發的改革大潮。從最初的敏捷培訓，到摸著路探索，也有4個月的時間了。現在，對於grooming，planning，daily stand up，demo review retrospective這些scrum中的活動已經清楚了很多。活動內容 grooming 梳...