前言
在 Scrum 的開發過程中，維護好 Work Items 是非常重要的一個步驟。這些 Work Items 會在Planning Meeting 或者是 Refine Meeting 被拿出來討論，如果內容定義不清，會導致討論會議的浪費，為了確保團隊在建立工作項目時有一致的認識和理解，以及在回顧過程中能夠更清楚地了解工作項目的緣由，此篇文章將介紹我在 Epic/Feature/User Story/Task 會寫的項目，以實際案例來分享，並簡單介紹如何在 Azure Board 裡面變成範本直接讓團隊套用
先來聊一下 Workitem 層級
在 Azure Devops 預設就有四種 Process 可以選，以目前 Agile 為大宗的開發模式，多半會選擇 Scurm/Agile，但這兩者基本上大同小異，如果要我一句話解讀這些 Item 代表的定義，我會這樣解釋:
- Epic: 高層老闆看的, 通常是公司的高大尚目標, 時間長度不超過1年
- Feature: PM或主管看的, 把高大尚收斂後的具體策略, 時間長度以季為單位
- User Story: PM/工程師看的, 達成策略的手段, 時間以1個sprint可交付為單位
- Task: 工程師看的, 達成手段需要拆寫的實作, 時間以1-2天為單位
至於這些 Workitem 該寫什麼? 以下章節來細部說明
我認為 Azure Devops 設計緣由可適用於大型組織，但導入需要逐步，也許小團隊可用 User Story+Task就可足夠了，太早一步到位反而會導致交付混亂
Epic
Epic 對我來講它代表了一個大型的、跨部門的產品目標，這個目標還沒有詳細的策略，也可以把它定義成是老闆的期望，也可以是 OKR 上層的指標，以 Product Owner 角度而言，我會思考如何傳達老闆的想法，並把它收斂成可量化的目標範圍，這會是一個半年不超過一年的時間長度，並需要有達成的指標，在標題上明確表達(e.g. 提升產品使用者滿意度 > 5%)，內容以描述這個需求的背景是什麼，經老闆與客戶的原話，有條理地闡述清楚，以 Azure DevOps Roadmap 來看，Updated Boards experience 這個層級的寫法就很適合當 Epic，屬於比較大方向的描述
Feature
Feature 會是要達成 Epic 所需要的策略，如果有 UX Team 配合的話，通常會是 Design Thinking 後的結果，或者也可以以呈現 Roadmap 的角度下去思考，讓團隊更好地了解當前專注的目標與的開發進度，特別注意 Feature 時間長度不應該超過一季，如果超過代表這個策略還需要再收斂。Feature 的內容會有點類似產品經理所撰寫的 PRD 文件，我通常會依據以下內容去做撰寫
- 問題敘述: 緣由與背景，清楚描述 Why?
- 產品假說: 需求的假設，提供什麼價值，能解決此問題 How?
假說可以用這種範本撰寫 We believe that {function} For {somebody} , Will achieve {outcome}
- 產品範疇: 這邊通常會定義最核心的 scope, 也可以描述哪些本次phase先不考慮
- 成功指標: 好的需求通常要能測量假說，擬定領先指標(lead metrics)可以在開發完成後做前後比較
- 未知風險: 可以多留一點初步想到的問題，在 Planning meeting 激發討論
User Story
在 Feature 層級清楚策略後，應該能再細拆要達成這個策略所需要做的事情，並且以使用者角度讓工程師理解使用者想要達成的功能。好的 Story 我覺得標題寫清楚就夠了，內容補充這張的重點並連結到 Feautre 或 PRD (看全貌的規格)
As a {somebody}, I want to {do something}, so that {some business value}
一個好的 User Story 應該要注意不能有相依性，可以獨立交付，必且撰寫出來要很明確甚至是能讓人快速有雛型畫面的，因為這些 Story 都是為了在 Planning Meeting 開啟對話，最重要的一點是要能估算，所以 Acceptance criteria (AC) 就變成是很重要的一件事，通常 AC 建議會用Given/When/Then撰寫，如果有 QA Team 的話也能從這些 AC 去長出更多的測試案例，以 Swimlane rules 這個改版功能為例，也是帶了 User Story 的寫法
Task
工程師具體要怎麼分工，前後端怎麼實作，DBA要準備什麼才能達成 Story 目標，這個層級我會放在 Task，撰寫內容不會太在意，標題也只要能區別目的即可，但這邊通常會有幾個規範，第一個是時間長度請拆解到 1-2 天可交付的單位大小，讓 Sprint 過程能反映到 Story 的完成度，另外 Code Review, 發 Pull Request 時候可以綁 Workitem 到 Task，讓 commit 的 code 能對應到原始需求。
Task 拆的細，越能掌握目前 Sprint 的健康指數，因為都可以回推到 Story/Feautre 的完成度
如何建立 workitem template
當單子都定義好，且團隊都有共識後，在 Azure Board 中可以將這些要寫的項目變成範本
且可以將它變成是一個 URL，每次開單時候可點擊這個網址進行套入
如果要維護 template 可以到 Project Settings -> Boards -> Team configuration 去管理
以上是針對 Workitem 自己的一些經驗與想法，當然要寫什麼，要拆什麼單子，還是回到各團隊自己定義出來
Reference