Sprint Planning 會議主要的任務, 是要規劃在這個迭代中, 要進行哪些事情. 在 LeSS 中, Sprint Planning 也和 Scrum 一樣, 分成兩個部分:

Sprint Planning 1 (SP1): 重點在決定要完成哪些需求. (What to do)
Sprint Planning 2( SP2): 重點在決定要怎麼完成這些需求 (How to do)

在 Sprint Planning 1, 需要參加的角色有 產品負責人 以及全體團隊成員, 或者是團隊找代表出來參加. 每個團隊可以找 1 - 2 個人來參加, 這樣可以提供團隊中 2 個不同觀點. 在 Less 框架中至多是 8 個團隊, 所以可能會有 16 人左右加入討論.

在派代表時有件事情需要提醒, 那就是不要派 ScrumMaster 當代表, 這個會議應該是需要找真的在做事情的人, 也就是雞和豬故事中豬的角色, 這樣討論時才能真的有效果. 當然啦, 有些團隊是一個人扮演兩個角色, 帶了團隊成員的帽子, 又帶 ScrumMaster 的帽子, 這樣是可以來參加 Sprint Planning 1 的會議.

產品負責人在介紹需求時, 可以有以下幾種方式來呈現需求

(1) 優先順序

產品負責人可以將要處理的需求, 依優先順序從上往下排列, 將需求貼在牆面上或是桌面上, 讓大家都看到. 這時候才開始介紹. 這樣的目的, 就是要讓團隊知道, 必須從最高拿到最低, 不能有較高優先級的需求沒人處理, 可是較低優先級的需求卻有人拿去.

(2) 故事地圖 (Story Mapping)

這個方式是要讓團隊知道這些需求的關聯性, 這個關聯性是從場景或是功能群組整理出來的. 因此, 這樣的方式對用戶來說比較容易理解.

為了鼓勵團隊能夠自組織, 我們會希望團隊自己去決定要拿哪一個需求來做. 讓團隊自己討論.如果有需要和其他團隊合作, 也讓他們互相去聯繫. 這樣可以讓產品負責人不要這麼累, 專心把需求和客戶搞定就好. 但是凡事都不太可能這麼美好, 難免會遇到團隊之間真的無法決定要誰來處理, 這時候產品負責人是可以幫忙做最後決定. 畢竟, 產品負責人負責整個產品成敗, 他是可能改變工作的分配.

如果我們在 Sprint Planning 1 過程, 常常要花很多時間討論需求, 可能是不清楚 或者是解法不確定, 抑或是架構設計有所遲疑. 這代表之前 Product Backlog Refinement 做得不夠, 有改進的空間.

在分配的過程中, 有件事情要注意一下. 不要讓高優先級的需求, 都集中在某個團隊. 這樣將會導致很大的風險, 如果這個團隊有狀況, 或是前面的需求卡關, 將會導致後面的都無法完成. 例如: 需求的優先順序假設是從 S1, S2, 到 S9. 這時候如果是下面這樣的分配, 就不太合適

Team 1: S1, S2, S3
Team 2: S4, S5, S6
Team 3: S7, S8, S9

改成下面這樣的話, 讓優先級可以比較平均散落在各個團隊, 有狀況時比較不會影響太大.

Team 1: S1, S6, S7
Team 2: S2, S5, S8
Team 3: S3, S4, S9