Sprint 為期如果是四週，通常會要求在八個小時內完成 Sprint Planning會議。Gavin 打算限制這個會議四個小時內完成，因為他們訂下的 Sprint 是兩週，一般都是按照比例來規劃會議時程。至於為何做時間限制，除了書本上都特別強調 Time-Box，他個人希望在這個專案看能否塑造出不加班就能有高效率，這是他接下這個案子內心很深的期許。

他列出的Product Backlog 待辦清單如下：

高優先

• 了解專案有哪些利害關係人，以及對此專案的期待或要求。
• 盤點現有AI相關技術中，哪些較有機會影響公司的未來生意。
• 框定專案範圍，聚焦於AI對公司有相關的某些領域。

中優先

• 提昇專案成員關於上述聚焦AI 的知識或技術。
• 專案團隊熟練 Scrum 運作
• 了解市場上AI趨勢，其應用推廣狀況
• 搭建 AI 執行環境 Phase I, Deep Learning Env.

一般

• 專案成員中現有關於AI知識的交叉訓練
• 建立知識庫，分享專案成果
• 推廣 Scrum 到利益關係人，讓專案更容易進行
• 與管理層探討此策略專案績效要如何評定

會議刻意選擇在下午兩點開始，這也許可讓大家更能把握時間，準時下班。
Gavin 簡單起個頭，讓大家知道這是粗略的待辦清單，需要大家一起合作從中遴選出這一個 Sprint 所要完成的事項。

Moore 看了清單提出異議： “『提昇專案成員關於上述聚焦AI 的知識或技術』 這項目標過大，不太可能在我們自定義為期兩週一個 Sprint 完成，同時他必須完成 『框定專案範圍，聚焦於AI對公司有相關的某些領域』

Gavin 笑著請 Molly 解危，Molly 說明：”Moore 看到的問題是對的。第一個原則：我們做的Sprint計畫工作內容必須在Sprint結束是可被驗證完成的，不能說完成80%，因為這無法驗證 。
其次基本上Scrum的計畫安排與大家在 UP/PMBOK 得到的經驗，，沒有任何違背。有工作前後相依性，也只能按照順序執行。至於一個 PBI, Product Backlog Item 工作量過大，無法在一個Sprint完成，那就是拆解。”

Pete 刻意問這個問題：”我個人感覺這個清單應該還有許多被遺漏掉的，尤其是跟利害關係人談過後，通常會突然間冒出很多需求來，運氣不好，很可能我們正在做的與大老闆要的是衝突的，那該怎麼辦”

Molly 趁機跟大家解釋：”這個問題是敏捷方法的核心，就是要因應軟體需求變更的特性。Scrum 與 UP 在這一點都是一樣的。首先，Sprint 時程為何不能太長，是因為萬一發生大需求變動，Product Owner發現與正在執行的Sprint有衝突， 可立即取消，然後安排新的Sprint。如Sprint太長，會提高Sprint計畫安排的風險。”

“這樣衍生的鼓勵大家在已獲得的需求中，勇敢的把高優先待辦事項納入。與其等待中空轉，倒不如先做一點。”

Cash請Gavin解釋他最感興趣的部份：
”其他全部工作都是喊很大要AI，就『搭建AI執行環境』為何突然侷限只有 Deep Learning? 落差頗大”

Gavin 解釋這是公司的文化，看大做小，規劃時要有全貌性的視野，但是執行起來，卻是一步一腳印，由小做起。

Fields 請教：”如果是軟體開發的事項，我們會說要通過 Test Case 當作完成的標準，我們也習慣 TDD, Test Driven Development，那這類行政相關的工作是否也要有測試案例？”

佳麗笑著搶答：”你已經融入公司文化了，其實如果做事前，能跟客戶或是需求者談好成功的準則，或者如何驗收之類的標準，這大概是你說的『測試案例』，那會加速雙方取得共識，減少誤會對方意思的尷尬。這不只是用在UP或 Scrum，用在其他工作上，相信對你自己的幫助很大。”

Molly思考了一下：”我沒注意到這點，不過我剛剛跟佳麗姐學到這要訣了。從Scrum 來說，諸如：剛剛佳麗姐提到驗收標準，成功準則，可以在Sprint 進行中逐步與 Product Owner 溝通取得。Product Owner 就算不屬於 Development Team成員，專案進行中還是需要相當多的互動。”

Moore：”我對這個『盤點現有AI相關技術中，哪些較有機會影響公司』待辦事項感興趣，但是我沒把握一個人有能力完成，有辦法解決嗎?”

“好問題，雖然Scrum 講要Development Team 一起承擔，但是工作管理方便上，我習慣將PBI待辦事項拆解到可以指定誰來當責，所謂當責並非一個人要獨立完成，而是他要嘛自己做完，要嘛知道找哪些資源協助完成，但是追進度都是由那個當責的來回答。更傳統的作法就是拆WBS到每個任務都有人當責。"