產品待辦事項清單很長；請謹慎投資並仔細深入。

產品待辦事項清單儲存、組織和管理您計劃在未來處理的所有工作項目。同時提供 敏捷培訓、諮詢和輔導服務 at Digital.ai我們公司（前身為 VersionOne）的客戶經常詢問如何以邏輯方式建立、組織和管理他們的產品待辦事項清單。客戶還想知道如何對工作項目進行優先排序。

這裡有一句簡單易記的短語，概括了管理良好的產品待辦事項清單的關鍵特徵：產品待辦事項清單要深入；明智地投資，謹慎地深入……否則，言下之意，你可能會沉沒（開玩笑，但只是略微開玩笑）。

下圖總結了組織良好且管理得當的產品待辦事項清單的關鍵特徵。 DEEP、INVEST 和 DIVE 這三個字意義重大，它們可以作為非常實用的縮寫詞，幫助我們記住這些關鍵特徵。在本篇部落格中，我將說明如何透過明智地進行 INVEST 和謹慎地進行 DIVE 來有效地管理一個 DEEP 產品待辦事項清單。

^{圖 1：管理良好的產品待辦事項清單的邏輯結構和關鍵特徵}

工作項目的粒度或大小應根據產品規劃的未來時間跨度（即規劃週期）來決定。規劃週期越長或越短，工作項目的大小也相應增加或減少。這是合理的，因為開發、規範和維護大量細粒度工作項目比開發、規範和維護少量粗粒度工作項目要耗費更多精力。較小的工作項目（使用者故事）通常是透過分解較大的工作項目（史詩級任務）而開發的。使用者故事是軟體設計、開發和價值交付的基本單元。

深度產品積壓

產品待辦事項清單可能包含數百個甚至更多的工作項，因此命名為 DEEP。工作項目可以由使用者故事、缺陷和測試集組成。 DEEP 本身也是一個有趣的縮寫，它概括了產品待辦事項清單的邏輯結構。

• D適當詳細：待辦事項中的工作項目依照圖 1 所示的適當詳細程度進行指定，如下所述。
• E估算準確：產品待辦事項中的工作項目的估算準確如下所述。
• E動態變化：產品待辦事項清單並非一成不變，而是會根據產品回饋以及競爭格局、市場和業務變化而持續演進或更新。新的待辦事項會被加入，現有事項會被整理（修訂、完善、細化）、刪除或重新排序。
• P根據需要進行優先排序：待辦事項清單中的工作項目會根據需要進行線性排序，如下所述。

衝刺規劃週期、工作項目粒度、估算和排序

如果規劃期是下一個時期，即即將到來的時期。 衝刺或迭代 （通常為兩到四周），每個工作項目都足夠小，可以放入一個迭代周期內，並且100%準備就緒（“完全就緒”），可以立即開始工作，如圖1所示——參見頂部紅色區域。一個完全就緒的故事已經被分析，具有清晰的定義（使用者角色、功能和業務價值）以及相關的驗收標準。計劃在下一個迭代周期中執行的工作項目包括使用者故事、缺陷和測試集。與後續迭代週期或後續發布週期中的工作項目相比，下一個迭代周期中的工作項目具有最高的優先權。我稍後會解釋這種優先排序是如何進行的。優先順序資訊用於決定團隊在迭代待辦事項清單中處理工作項目的順序，以及決定在迭代時間盒結束時將哪些未完成的工作項目推送到發布或產品待辦事項清單中。

下一個迭代週期中的工作項目整體上滿足著名的 INVEST 標準；INVEST 既是一個有意義的英文單詞，也是一個由 Bill Wake 創造的有趣的縮寫（參見他的博客）。 投資故事和智能任務）。它的字母代表了下一個迭代待辦事項清單中工作項目的重要特徵。現在我將詳細解釋 INVEST 縮寫中的各個字母。下一個迭代待辦事項清單中的使用者故事應該具備以下特點：

• I彼此獨立：在規範層面，各個使用者故事是相互獨立的；它們提供截然不同的功能，並且互不重疊。此外，在實現層面，這些使用者故事也應該盡可能地彼此獨立。然而，有時某些實現層面的依賴關係可能是不可避免的。
• N可協商：下一個迭代中的故事始終需要產品負責人（業務代表）和敏捷開發團隊成員之間進行協商和澄清。
• V可用性：下一個迭代的每個使用者故事都應為外部使用者或客戶（開發團隊之外的群體）、團隊本身或利害關係人提供明確的價值或利益。對於大多數產品和項目而言，大多數使用者故事都能為外部使用者或客戶帶來價值。
• E可估算性：敏捷團隊應該能夠根據使用者故事的描述來估算實現該故事所需的工作量；這種估算通常以相對規模（故事點）來表示，也可以選擇性地以時間單位（例如整個團隊的理想工時或工作天數）來表示。因此，使用者故事的估算通常以故事點為單位，也經常使用理想時間單位。
• S適當化：對此標準的更簡單解釋是，每個故事 S規模足夠小，可以在一個迭代周期內完成並交付。字母“S”可以理解為 S適當調整；具體來說，在為期 N 週的迭代週期中，每個使用者故事的團隊工作量不應超過 N/4 人週（請參閱 Larman 和 Vodde 於 2009 年出版的《精實敏捷開發規模化》，第 120 頁）。因此，對於兩週的迭代週期，每個使用者故事的工作量不應超過 2/4 人週 = 0.5 人週 = 20 人時。總工作量遠超過 20 人時的使用者故事應被視為史詩級使用者故事，並拆分為較小的使用者故事。對於四周的迭代週期，每個使用者故事的工作量不應超過 4/4 人周 = 1 人週 = 40 人時。如果迭代待辦事項清單中包含大小不同的使用者故事（其平均值遠超 N/4 人週），則所有使用者故事的平均週期時間將顯著增加，從而降低團隊速度。
• T穩定性：每個故事規範都非常清晰，可以根據其驗收標準（這是規範的一部分）制定所有測試案例。

使用者故事可以分解為具體的實現任務，例如分析、設計、程式碼開發、單元測試、測試案例開發、線上幫助等等。這些任務需要符合 SMART 原則：

• S： 具體的
• M可衡量的
• A可實現的
• R： 相關的
• T限時任務（通常足夠小，可以在一天內完成）

如果一個使用者故事所需的團隊工作量不超過 N/4 週（例如，兩週迭代周期內為 20 個工時），那麼該使用者故事中的所有 SMART 任務加起來也應該不超過 N/4 週。若有五個任務，每個任務平均應花費四小時或更少的理想工時。使用者故事及其 SMART 任務值得投入下一個迭代周期中，因為這種投入的回報很高，它們將在下一個迭代周期內完成並交付為可工作的軟體。

Release 計劃週期、工作項目粒度、估算和排序

如果規劃週期為即將到來的發布週期（通常為 8 到 26 週，或 2 到 6 個月，包含多個迭代），則工作項目為“中等粒度”，如圖 1 中間黃色區域所示。通常，這些工作項目中有很多是史詩級任務；但是，它們仍然應該足夠小，可以納入一個發布週期，並且可以在一個發布週期內的兩個或多個迭代中完成。這些史詩級任務通常被稱為特性或特性史詩。這些特性史詩仍然應該使用使用者角色、操作、價值和驗收標準的形式化方法進行描述，這種方法通常用於描述使用者故事，但現在您捕獲的是特性史詩所代表的更大的功能。特性史詩在要實現該故事的迭代之前，會被拆分成足夠小的故事，以便在一個迭代中完成。

在整個時間範圍內 發布週期對整個發布週期內的用戶故事進行投資的回報很差，因為要確保涵蓋整個發布週期的大量用戶故事都正確滿足投資標準需要付出很多努力，而且這些用戶故事在跨越多個迭代的發布週期中更有可能發生變化；因此，這種投資可能不會產生預期的結果，因為用戶故事在指定之後很可能會在整個發布週期中發生變化。

在發布週期中，功能史詩可以而且應該以相對規模來估算，但無需耗費精力將發布週期中的所有功能史詩分解成單一使用者故事。這種史詩級估算可以透過比較史詩的相對規模來實現。這種方法確保所有史詩和使用者故事都以「標準化故事點」這個通用單位進行估算，該單位代表了整個組織內所有專案、迭代、發布週期和團隊的相同規模。無需使用與故事點完全無關的“小數”或“規模數字”來估算史詩。

在發布週期中，對功能史詩進行排序仍然有意義，這可以決定哪些功能史詩會在第一、第二、第三迭代中安排開發。但是，隨著每個迭代的完成以及更多資訊和經驗的積累，這種分配方式可能會發生變化。

產品規劃週期、工作項目粒度、估算和排序

如果產品規劃週期跨越多個發布週期（通常為 6 至 24 個月），超出當前發布週期，則工作項目將採用「粗粒度」劃分，如圖 1 底部灰色區域所示。這些大型史詩或超級史詩需要兩個或多個發布週期才能完成。這些超級史詩可以用簡單的英語（項目符號文字）來描述，也可以使用螢幕模型、影片、原型或其他任何能夠清晰表達其意圖和價值的方式進行呈現。在實施這些超級史詩的發布週期之前，它們會被拆分為足夠小的功能史詩——這些功能史詩足夠小，可以在單一發布週期內完成。

從多個發布週期來看，對使用者故事進行投資的回報甚至比在單一發布週期內進行投資還要差。這種投資方式無法產生預期效果，因為使用者故事在多個發布週期的較長時間內很可能會改變。

需要多個發布週期才能實現的大型史詩或超級史詩，可以而且應該用相對規模來估算，但無需耗費精力將大型史詩拆分成功能史詩，再將功能史詩拆分成用戶故事。這種估算可以透過比較大型史詩的相對規模來實現。

在多版本發布週期的產品規劃範圍內對大型史詩級任務進行排序可能意義不大，因為隨著時間的推移，任務優先級很可能會發生變化；此外，即使一個未來 6 到 24 個月內才會啟動的大型史詩級任務的優先級排在 125 位，也無關緊要。^th 或126^th不需要達到那種排名順序的精確度。

我採用的策略是，只在下一個迭代的待辦事項清單中投入資源來建立使用者故事和 SMART 任務，而不會在發布或產品待辦事項清單層面進行此類投入。在規劃下一個迭代時，只需及時投入即可。長期投入使用者故事和任務的回報將很低。

仔細深入分析產品待辦事項清單。

時間和資源往往不足以完成所有事情。因此，敏捷團隊必須對使用者故事進行優先排序（更準確地說是排序），確定哪些使用者故事需要優先處理，哪些優先順序最低的使用者故事可以在迭代周期臨近結束時被移出範圍。對於敏捷開發項目，應該對產品待辦事項清單進行線性排序，而不是採用粗粒度的優先級排序，即將用戶故事和史詩簡單地歸入少數幾個優先級類別，例如低、中、高和關鍵優先級。線性排序（例如，1、2、3、4……n）可以避免優先級膨脹，確保每個人都誠實對待優先級，並迫使團隊專注於真正重要的事項。它還能防止業務部門聲稱所有事項都具有高優先級或同等重要性時，出現「孩子進了糖果店」的衝動行為。

請注意，史詩和故事在概念上有所不同，在製定排名時不應混為一談或合併。史詩排名與故事排名是相互獨立的。

敏捷優先排序的責任由團隊所有成員共同承擔；然而，優先排序工作由產品負責人主導。與 DEEP、INVEST 和 SMART 類似，DIVE 既是一個有意義的英文單詞，也是一個縮寫。產品待辦事項清單項目應該 線性排序 基於 潛水 這個標準需要仔細考慮DIVE縮寫詞所代表的所有四個因素：

• D依賴關係：即使盡可能減少使用者故事或史詩之間的依賴關係（這始終是好事），仍然可能存在一些不可避免的依賴關係，這些依賴關係會對優先排序產生影響。如果工作項 A 依賴 B，則 B 的優先權必須高於 A。
• I防範風險：包括業務風險和技術風險
• 商業 VALUE
• 預計 E努力

_{表 1：透過明智的投資和謹慎的分派來管理深度產品積壓的總結}

我希望您覺得「產品待辦事項清單很深；明智地投入，謹慎地深入」這句話是一個有用的記憶口訣，可以幫助您記住管理良好的產品待辦事項清單的關鍵特徵。

了解更多關於敏捷性如何幫助您的企業成功的信息 Digital.ai Agility.