Backlog Refinement 帶領你把願景兌現成價值

2023/05/12閱讀時間約 6 分鐘

本文已取得 Scrum Inc. 官方授權翻譯，原文為：Backlog Refinement Takes You from Vision to Value https://www.scruminc.com/backlog-refinement-vision-value/ (全文視情況刪減或調整，以幫助閱讀)

*本文「refine」譯為「精煉」、「7 Product Dimensions」譯為「七項產品特點」、「Structured Conversation」譯為「結構化會談」，以及「Enabling specification」譯為「能用之規格」；本文的「Story」均指「User Story」。

更快的交付價值

Backlog Refinement 能為開發而準備好你所需的 Backlog 。投資此事，能幫助你更快的交付價值、倍增你的生產力，以及建立強大的協作 —即高績效團隊的支柱。我們發現 Product Owner 在 Backlog Refinement上，需要更進一步的訓練。透過極度專注在價值，以及進行運用七項產品特點（7 Product Dimensions）的結構化對會談（Structured Conversation），你會大幅提升把願景兌現成價值的能力。

Refinement 是關於「持續準備好（Readying）」

精煉 Product Backlog 是以某種方式為 Sprint Planning 準備好 Backlog Item ，這種方式包含分析和切分 Story。一個健康的 Backlog ，是由 Product Owner 持續精煉的，以提供給團隊詳細說明、作為估點、評估價值與排序 Backlog Item 用。這項持續精煉的工作，能快速和增量交付（incremental delivery）產品價值，同時也是最佳化開發團隊生產力的關鍵。根據 Jakobsen 和 Sutherland 的研究指出，為了進行 Sprint Planning ，而已先及時被適當精煉的 Product Backlog Item，能倍增團隊的生產力。（請見參考書目1）

然而，團隊卻苦於有效率（時間）且有效果（成效）的做出這項重要的工作（指 Refinement）。當他們浪費時間在對於整體產品價值不重要的 Backlog Item 上，或因為東西太大或模糊，而導致無法執行或展示時，他們會猶豫且難再進行下去。

從價值開始，及從價值結束

當一個成功產品與它的願景和目標保持一致時，它就能產生價值。當產品提供合理報酬，以換取時間、金錢、商品或服務時，它便會產生價值。

Refinement 假定 Product Owner 和開發團隊合作，基於價值，而替 Backlog 排序。Refinement 需要做出艱難的決策，這項決策是基於平衡「不同利害關係人的價值觀點」與「根據持續變化的市場條件和客戶需求而隨著時間改變的價值」而作出。

基於價值而建立的 Backlog Refinement 之決策，需要 Product Owner 和團隊間的協作。建立信任，則應該揭露影響整體開發生命週期的「無法避免之取捨」的「複雜性」。比如：有些 Sprint 也許需要團隊承擔短期技術債，以便在高度競爭市場上，保有與其他產品一致，而所需交付的功能。其他 Sprint 可能需要團隊推延所需做的功能，到比較後面的 Sprint ，以便關注在減少違規（regulatory noncompliance）的風險。

每個產品和其關聯的 Backlog Item 都有七項產品特點，這包含功能需求（使用者、行動、數據和控制特點）與非功能需求（介面、環境和品質屬性特點）。（請見參考書目2）

這七項產品特點提供正在開發中的產品，一份統一、完整與全面詳盡的理解。Backlog Item 的全貌，強調沒有任何一項特點本身是足夠的 — 即這全部七項都是必須存在的。透過探索這些特點，每個人對於 Backlog Item 的了解，應該都能從改善後的（結構化）會談而獲益。

結構化會談，幫助你做出有價值的拆分

在 Backlog Item 被精煉的同時，團隊需要一種機制來鼓勵其探索、評估和進行確認。這種持續且有系統的方法，被稱為結構化會談。

結構化會談的概念，源自於一個對團體協作和創新有用的工具。它鼓勵以更有效的方法來探索、評估和確認選項。

一開始，團隊由七項產品特點來為 Backlog Item 探索選項。接著，團隊評估高價值選項的子集（subset），再將他們組成有價值的集合體。直到每個人藉由確認每個 Story 如何被展示和驗證，以確認他們有共同的理解後，這會談才會結束。

精煉並運用結構化會談和七項產品特點，來揭露相依性，並使團隊著重在可行動與有價值的 Story 上，而這些 Story 是足夠小的，以致於能被評估，且在一個 Sprint 中被完成。能用之規格，通常是這些會談的副產品，而且其補充了更多複雜的 Story。（請見參考書目3）

能用之規格包含 wireframes（介面特點）、資訊模式圖（數據特點）、決策表（控制特點），或相似的視覺分析模型。舉例來說，團隊應該以對遵循規則最有用的、產品支援的參考資訊和不具備產業知識（domain knowledge）的團隊成員，來確定建立的能用之規格的優先順序。

參考書目：

1. Jakobsen, C.R. and Jeff Sutherland, J. “Scrum and CMMI — Going from Good to Great: Are you Ready-Ready to be Done-Done?” Agile Conference, IEEE Conference Publications (2009): 333–337.

2. Gottesdiener, Ellen and Mary Gorman. Discover to Deliver: Agile Product Planning and Analysis. EBG Consulting. 2012.

3. Sutherland, Jeff. “Enabling Specification: The Key to Building Agile Systems.” Scruminc (blog). June 2, 2012.