Scrum的Plan、Review 和 Retrospective

圖片來源：網路

延續上一篇"Scrum大師講座心得"裡面提到的，一個Scrum Sprint (iteration)有幾個重要部分：

• Sprint Planning Meeting  (這邊有分 Part 1 和Part 2)
• Daily Scrum 
• Product Backlog Refinement (至少要保留5~10%的時間做 Refinement)
• Potentially Shippable Product Increment (PSPI)
• Review Meeting (這邊也有分Part 1 和 Part 2)

其中我認為最重要的部分就是頭尾的兩個Part1 與Part 2

• Part 1 是由 Product Owner 主導，跟釐清需求、做什麼有關 (What to do)
• Part 2 是由 Team member 主導，跟如何做做多少有關 (How to do and how much )。

而整個Sprint循環的精神就如同下圖所示：

圖片來源：自己整理

聽到這個概念，我就開始自我檢討，發現我們在跑Scrum的iteration時都把Part1 與Part 2 混在一起，而且都比較忽略了Part2的部份， 尤其是Sprint Retrospective的部份，所以Scrum等於只用了半套，而在這種一知半解，不了解其精神與實際意義的狀況下，就貿然就去使用，其實比不知道更危險沒使用還更危險，也更容易讓專案失敗。下面是就我現在的認知與理解，整理每個階段應該做什麼，跟應該注意什麼。

Sprint Plan Meeting Part1 

(What to do?)

Part 1主要是由Product owner(PO) 跟所有team member 有以下的互動：

1. PO說出希望在這個iteration結束可以看到怎樣的成果
2. PO依據product backlog上希望被完成的user story，一一講解內容
3. Team member 會針對user story 把所有的細節都問清楚 (有點像傳統的SA)
4. Team member 透過porker game，把每個user story 估計一個數值(Story point)
5. PO就可以參考這個story point以及其他因素(Value、Cost、Risk...等)再把所有user story 排序(prioritize)
6. Team member 挑選出承諾可以在這個iteration完成的工作量
7. 最後產出一個可以用一句話描述完的目標 (比如說讓使用者可以登入網站，並且可以看到xxx，和有xxx的功能。)

Sprint Plan Meeting Part 2 

(How to do and How much)

緊接著 Part 2 meeting (這時PO可以退場，最好也退場)，然後讓Team member 針對剛剛選出來的User story 開始討論，並且有以下動作：

1. 討論User story 的技術細節該如何實作 (有點像傳統的SD)
2. 把User story 切分為可被預估時間的工作(Task)，並且估計時間
3. 最後大家自由認領工作(可以跟2一起做，由認領的人預估時間)。

那這跟我們之前的作法有啥差別？我們之前事一開始就跳到預估時間，把它跟story point混在一起談，這其實是很危險，而且誤差會很大的。

           

圖片來源：A Sad Face by Emmaline

看完了Plan meeting，接下來就是要來談Review meeting，傳統來說講到要review，可能大多是哭臉大於笑臉吧。可能腦袋浮現的就是批鬥大會，批評檢討為什麼東西做不好，為什麼會有bug，為什麼會delay....等。但這都不是Review meeting 的本意，Scrum 的最重要精神是改善" incremental improvement "。所以下面我在來整理一下Review 與 Retrospective 要做什麼。






話說回來，其實不只是我們，老外也是很害怕Review meeting(應該是工程師都怕吧?XD)，從 The Sprint Review: Mastering the Art of Feedback [1]這篇文章節錄一段話：

The sprint review in Scrum is a critical part of the inspect and adapt cycle. Having worked with many teams and organizations, I have noticed an overall reluctance (and in some cases fear) to do them in the way they were intended. Too many companies and projects set up their sprint review so that the team is presenting to the Product Owner, as if he should grade them or judge them on their work.  This is nonsense! The Sprint Review is not an inquisition or a court of law; it is a way to get feedback from the customer. Instead of presenting to “Judge Product Owner,” teams should instead work with the Product Owner during the sprint to review each story as it’s completed.

Sprint Review Meeting 

(Review what to do)

Sprint review meeting 最主要的用意就是用來與客戶(stakeholders)交流，並且展示team所要交付的價值，而這個會議應該是由Product owner主導，展示以下內容：

• 展示團隊成員承諾要交付的工作項目(與價值)
• 展示團隊成員完成了什麼工作(有達到哪些目標，有哪些沒有達到)
• 在Sprint 中間有達成麼重要的決定 (不管是技術、需求..等)
• Project metrics (burn-down chart、velocity、code coverage...等)
• 展示現階段交付的軟體品質到什麼程度 (The quality level of the product)
• Demo
• Priority review (for the next iteration/sprint)

中間也可以穿插由team member 帶著自豪的講解自己做了什麼功能與提供了什麼價值。在Demo與講解完後，藉由此機會所有人可以面對面的交談，Product owner 與 Team member 就可以由客戶那邊得到feedback(針對交付物 or 產品 的功能)，也可以更了解客戶的想法，客戶也可以提出有哪些需求變更要放入backlog和下一階段。

Let's all ! 這個時段只屬於成果展示和接受feedback的時段。

(以兩週一個Sprint，會議時間盡量控制在1hr)

Sprint Retrospective Meeting

(Review how to do and how to improve)

接下來的Review part 2 - Retrospective才是重頭戲，Team member 和 Scrum Master 要一起坐下來討論 (Product Owner 必須退場)，主要討論的議題有兩個，在這個sprint裡面：

• 有什麼(人或事)做的不錯的，可以被感謝和稱讚的
• 有什麼(人或事)是需要檢討，以及在下一個sprint該如何改善

圖片來源：網路[3]

因為Review 的意義在於如個改進，如讓團隊更強壯，如何提昇整體的velocity (就像右圖一樣)， 所以為了要讓整個會議是有意義的，下面列出retospective的重點 [3]：

• 讓大家可以自由的發言 (而且大家都要有發言)
• 檢討不是批判，不要變成批鬥大會，對事不對人。
• 不要有模糊的發言，大家要訓練表達能力 ~XD
• 所有改善建議須要有具體且可行的方法。
• 把這些建議和行動方案(action plan)都記起來，並且確保下次有做到，不要開完會就忘了。
• 控制整個會議時間 (time-boxed)

(以兩週一個Sprint，會議時間盡量控制在1hr~2hr 之間)


不過整理的這些東西只是讓我更了解Agile 和 Scrum的精神，但要真正落實下去還是有很多手法和眉角，要學習的道路還是很漫長啊~~Orz..


延伸閱讀：
[1] The Sprint Review: Mastering the Art of Feedback
[2] Sprint retrospective vs. Sprint review
[3] Unleashing the Full Potential of Sprint Retrospective Meetings 
[4] Intro to agile