在 Scrum Guide 中提到 Sprint Planning 2 中要進行以下事情：

主題三：如何完成所挑選的工作？
對於每個選定的 Product Backlog item，Developers 會計畫必要的工作，以便創造符合完成之定義的 Increment。這個過程通常會把 Product Backlog items 拆解成等於或小於一天的較小工作。但要如何拆解是完全由 Developers 來決定。沒有人告訴他們要如何把 Product Backlog items 轉化成具有價值的 Increments

因此, Sprint Planning 2 的重點在於規劃如何完成. 這個部門大多是團隊成員來討論, 因為他們是主要做的人, 是弄髒手的人, 出一張嘴的這時候就不需要參與討論. 但是這時候如果你可以根據經驗提供建議, 或是幫忙檢視是否有遺漏, 還是可以一起加入討論. 像是架構師, 或是對於某個領域知識或設計很有經驗的專家.

因為是要列出為了完成這些需求所需要進行的工作(task), 很多時候他們會在這個會議中, 翻閱之前的代碼, 了解之前系統運作方式, 來輔助他們思考這次需要些改哪些部分 進而想出所要進行的工作. 在這個過程, 可以搭配 pair programming 的方式, 讓 2 個或多個人一起來看之前的代碼, 一方面可以知識交流傳承, 讓比較多的人知道原先系統是怎樣運作的. 另一方面, 可以藉由多隻眼睛, 讓該注意的事情有被提醒, 哪些工作需要做, 哪些地方需要小心等等.

這裡可以有一種進行方式供大家參考. 假設我們有 8 個需求需要在這個迭代內進行, 我們團隊有 6 個工程師.

14:00-14:05 將人員分成兩組, 每組 4 個人. 然後將需求平分到這兩組中
14:05-14:35 大家一起對所分到的需求進行討論, 思考要如何完成此需求
14:35-14:40 休息, 或是詢問是否需要再多點時間
14:40-15:20 分享他們大約如何設計來完成這個需求 (每個需求至多 5 分鐘介紹和問答)
15:20-15:50 需求認養並且展開所要進行的工作
15:50-16:00 休息
16:00-16:40 展示每個需求需要處理的工作 (每個需求至多 5 分鐘介紹和問答)
16:40-17:00 總結或最後的問答

雖然我們花了一點時間, 但是在一開始就一起做了初步的設計, 讓大家的意見有被交流. 可以讓大家列出來的工作是有品質的. 並且可以在這過程中, 有機會發現可能你認養的需求是做不完, 或者是有些地方是不清楚的, 導致團隊無法在迭代中完成這些需求. 早點讓產品負責人知道, 這樣就可以早點做些處理, 來面對這樣的狀況.

在 LeSS 中, Sprint Planning 2 可以分成以下方式進行：單團隊 Sprint Planning 2 和多團隊 Sprint Planning 2.

圖片來源: https://less.works/less/framework/sprint-planning-one

(1) 單團隊 Sprint Planning 2

這個部分就跟以前 Scrum 一樣. 所以要注意的事情, 可以在之前 Scrum 相關文章中可以找到.

(2) 多團隊 Sprint Planning 2

這部分通常是發生在需求有點複雜, 或這是要做的團隊不熟悉, 需要其他團隊幫忙, 這時候我們就需要多個團隊一起來討論, 要如何才能完成這個需求.

在多團隊進行時, 通常我們會進行設計工作坊. 舉行的時間可能在 Sprint Planning 2 或者 Sprint Planning 進行完後立刻召開. 如果可以的話, 我建議是在 Sprint Planning 2 中針對某些複雜的需求來進行. 這樣才能比較能確認要進行工作是什麼. 不會在 Sprint Planning 2 瞎掰後, 等到 設計工作坊後又翻盤. 最怕的還是跟產品負責人完成不了, 到時候產品負責人還要將需求拆解, 或者是重新再安排不同團隊負責的需求, 這樣重工的代價太大.

Pic source: https://geekytheory.com/como-escribir-buenas-historias-de-usuario/

這時候我們會需要個大白板, 大家在上面討論, 把設計的資訊給視覺化. 所以你會需要有 UI mockup, 操作流程圖. 並且你會利用 UML 的圖形來呈現系統的設計, 像是 class diagram, sequence diagram 等等. 在這個過程中這些模型不一定表達完全的正確, 但是重點在於他們能幫助對話, 大家可以把心中的假設和想法呈現出來, 讓大家可以共同檢視和了解.

參加多團隊討論的人選, 不一定要所有成員都參加, 但是希望每個成員都可以有代表參加, 讓這些成果和決策原因, 可以有不同團隊的觀點, 並且之後也可以帶回去. 如果可以話, 來參加的人選盡量是可以貢獻的, 如果不行的話, 是否有機會一個懂的帶一個不太懂的, 讓不懂的可以有機會學習. 然後懂的人是可以真正有所貢獻.