上個月〈Product backlog refinement 的必要性〉那篇文章,自認有點匆促,沒有把腦袋裝的都寫出來。正好最近敝公司某幾個團隊,已經走到可以正式探討是否該引進 refinement meeting 的階段,我就來補充一些論述吧。

尤其是針對文末「Sprint Planning 是一整個 Sprint 士氣的火車頭,不宜消耗在梳理瑣事上」這段論述。



先以傳統的專案管理角度來類比(Scrum 純粹論者,請先不要挑剔這類比是否允當)。

我一直認為,某方面來說,Scrum 的 Sprint,其實可以類比成傳統的 project,只不過是一個相對規模較小的專案,是個時程極短的專案,是個範疇較小、成本較低、風險較低的專案。

因此,Scrum 的 Sprint Planning meeting,其實很像傳統的 project kickoff meeting(專案啟動會議),只不過啟動的,是一個相對規模較小的專案。

試問,傳統的專案啟動會議,會做些什麼呢?以及,在啟動會議之前,會做些什麼呢?


PMBOK 角度

讓我們看看一代經典 Rita Mulcahy 的 PMP Exam Prep, 8th edition 吧。

作者精心設計的 Rita's Process Chart 中,特地將 "Hold kickoff meeting" 活動列為 planning 流程的最後一項:

PLANNING (This is the only process group with a set order)

  • Determine how you will plan for each knowledge area
  • Determine detailed requirements
  • Create project scope statement
  • ...
  • Finalize the "how to execute and control" parts of all management plans
  • Develop realistic and final PM plan and performance measurement baseline
  • Gain formal approval of the plan
  • Hold kickoff meeting

整段列表,點出一則 kickoff meeting 關鍵:

  • 時間點:Kickoff meeting 發生在已有 "realistic and final PM plan" 及 "performance measurement baseline" 之後。

在 "Integration Management" 一章 p.131 則是如此介紹 Kickoff Meeting 的:

Kickoff Meeting  Before the Develop Project Management Plan process can really be completed and project executing can begin, a kickoff meeting should be held. This is a meeting of the key parties involved in the project (e.g., customers, sellers, the project team, senior management, agencies, functional management, the sponsor). The purpose of this meeting is to announce the start of the project and to ensure everyone is familiar with its details and with the people working on it. In other words, the meeting is held to make sure everyone is on the same page. In addition to introducing those involved in the project, the meeting may review such items as project milestones, project risks, the communications management plan, and the meetings schedule.

整段敘述,點出兩則 kickoff meeting 關鍵:

  • 時間點:Kickoff meeting 發生在 "Develop Project Management Plan" 之後,發生在 "Executing Project" 之前。
  • 核心活動:宣布專案正式開始,確定全體都理解專案細節。可能也會順便檢視專案管理計畫。

另一本我很喜歡的書 Project Manager Street Smarts: A Real World Guide to PMP Skills 對於 kickoff meeting 的說法是:

You have completed the daunting task of planning your project. You want to get this plan approved so you can conduct a stakeholder kickoff meeting and actually begin executing the project.
Obtaining approval should be easy as this point, as long as you have kept your stakeholders in the loop and have created a plan that provides management and customers, as well as your team, a level of confidence that the project will be successful if the plan is followed.

因此,以 PMBOK 角度來說,kickoff meeting 現場,其實已經不太會有過多的 surprise 了。該有的討論或爭論,該有的重要 performance measurement baselines (scope baseline, schedule baseline, cost baseline) 應該早在 kickoff 之前就與相關人士協作進行到某個地步了。

Kickoff meeting,其實幾乎可算是破土儀式。而且是集體合意的,集體對 planning 的產出物 “Project Management Plan” 表示合意。


類比角度

類比到 Scrum 身上(Scrum 純粹論者,請先不要挑剔這類比是否允當)。

既然 Scrum 的 Sprint Planning meeting,可以類比成傳統的 project kickoff meeting,只不過啟動的,是一個相對規模較小的專案。那麼,前面那些 kickoff meeting 論述,自然也可以套用在 Sprint Planning 身上:

Sprint Planning 現場,其實已經不太會有過多的 surprise 了。該有的討論或爭論,該有的重要 performance measurement baselines (scope baseline, schedule baseline, cost baseline) 應該早在 Sprint Planning 之前就與相關人士協作進行到某個地步了。

Sprint Planning,其實幾乎可算是破土儀式。而且是集體合意的,集體對 planning 的產出物 “Sprint Backlog” 表示合意。

這些,就是強烈支持在第 N 回 Sprint Planning 會議之前,至少要先有第 N-1 回的 “Product Backlog Refinement” (PBR) 的論點,好先將 backlog 提煉釐清梳理到 “ready” 的地步,提煉到可以直接端上第 N 回 Sprint Planning 會議討論的地步。


敏捷大師角度

也聽聽 Scrum 發明人 Jeff Sutherland 是怎麼介紹 definition of ready (DoR) 的吧:

Gojko Adžić 在《Specification by Example》也說:

真正的討論,其實是在確立工作內容之後才正式開始。

Sprint 正式開始之前,每個團隊將至少擁有一至兩個故事,且各自具備已經對自動化做好準備的、詳細的、附帶實例的 spec。 [...] 故事在計畫會議裡進行審核時,該故事的驗收標準通常已經確定好了。

如果每個人都覺得「完成某個故事所需的資訊」已經足夠,就在那張故事卡上貼一張藍色的貼紙,表明那個故事「可以進行開發」了。

過猶不及。大師 Mike Cohn 在 "The Dangers of a Definition of Ready" 一文中,嚴正警告不要落入 "stage gate" 的回頭路,並鼓勵 concurrent engineering:

When a Definition of Ready includes a rule that something must be done before the next thing can start, it moves the team dangerously close to stage-gate process. And that will hamper the team’s ability to be agile. A stage-gate approach is, after all, another way of describing a waterfall process.
Agile teams should practice concurrent engineering, in which the various activities to deliver working software overlap. Activities like analysis, design, coding, and testing will never overlap 100%—and that’s not even the goal. The goal is overlap activities as much as possible.

難怪 Gojko Adžić 會在《Specification by Example》不斷強調團隊協作的重要:

成功的團隊,不會依賴於某個人獨自去收集正確的 spec,而會與商務使用者一起協作制定解決方案。

書中也建議,將 SBE 活動,放到 Scrum 的 PBR 時段中:

Bas Vodde 和 Craig Larman 建議 PBR workshop 應該佔每個 iteration 中 5%~10% 的時間。

要在成熟的 Scrum 團隊施行 SBE 有個簡單的方法,就是在 PBR workshop 中「舉例說明」需求。

我們認為每週或每兩週有一次這樣的活動是個良好的習慣,能用來確保產品功能清單頂部的故事都能很容易直接拿來實行。 [...] 如果發現很難達成一致的意見,我們會試著分解故事,直到所有內容都十分清晰,而大家都對工作量的評估結果表示認同。


結語

Sprint Planning 是一整個 Sprint 士氣的火車頭,不宜消耗在梳理瑣事上。

欲達此境界,就請先重視 Product Backlog Refinement 這個前置作業吧。


▷ 後續文章:〈Product backlog refinement 文章小蒐集