這是我在 .NET Conf Taiwan 2022 的演講 - 那些年用 Azure Boards 交付過的產品 以 5 個痛點來分享之前 Scurm 所遇到的問題，當時怎麼解決， 並將其整理成為文章版更難完整記錄本場的內容 複雜度評估的兩個方式 在 Azure Boards 裡面可以安裝 Estimate 這個套件，在 Planning Meeting 的時候可以針對 User Story 進行估點計算，且這是一個線上即時的功能，即使遠端協作的團隊也可以達到很好的估點流程 這工具在出點的時候可以一起呈現，如果彼此點數落差大，可以進行多輪的討論，我們通常會用相對點數來讓團隊取得共識，此套件也能選擇很多範本 但如果你今天是有海量的需求，不想花太多時間一張一張評估，也許可以用 Affinity Estimation 這種方式，他的執行步驟是由PO解釋完單子後，將所有單子都建在看板上，透過團隊共同拖拉的方式，越左邊代表複雜度越小，越右邊越複雜，之後取中間當個分隔線，在給予不同大小的渠道。 最後一個步驟是針對鄰近的單子去比對，兩個大小是否是差不多大小，如果落差過大再微調 延伸閱讀: https://www.techagilist.com/agile/scrum/affinity-estimation-agile-estimation-method/ 如何知道團隊成員工作量? Planning 另外一個重點就是在 User Story 底下去拆技術細節去分工(Task)，雖然估時估不準，但我會建議還是能在 Original Estimate 這個欄位讓工程師評估一下這個單子預計要花的時間，通常一天我們會以 6hr 為單位，如果 Task 評估大於 12hr，代表顆粒度太大，需要再細拆，為什麼要這樣做呢? 因為搭配 Capacity 針對每個工程師每日可貢獻的時數，可以讓我們知道每個工程師拿的量會不會過多或過少 但記得一點，不要用這個來挑戰工程師產值，敏捷強調自我管理，信任制，為了共用目標努力，太在乎每日產出只會造成工程師給錯誤的資訊 在 Planning 檢視每個人的工作量是否平均 如果你想要看完整的演講影片，現在也已經傳到 Youtube 影片: https://www.youtube.com/watch?v=G0ggjY5kzF8 簡報: https://speakerdeck.com/kyleshen/dot-net-conf-taiwan-na-xie-nian-yong-azure-boards-jiao-fu-guo-de-chan-pin 5篇 Scurm 痛點文章 Product Owner 需維護好 Backlogs, 但怎麼判斷價值順序?...

這是我在 .NET Conf Taiwan 2022 的演講 - 那些年用 Azure Boards 交付過的產品 以 5 個痛點來分享之前 Scurm 所遇到的問題，當時怎麼解決， 並將其整理成為文章版更難完整記錄本場的內容 在 Mike Cohn 的 使用者故事一書中，有提到一個好的 User Story 應具備以下內容 獨立的 (Independent) 為了提高產品開發效率，User Story 必須盡可能獨立，與其他單子的依賴性越低越好。這樣可以讓團隊更好地分配工作，並使開發流程更加靈活和高效。當 User Story 之間有很強的相互依賴性時，只要一 Delay 可能就會影響其他單子的進度，進而影響整個產品的交付。因此，將 User Story 設計為盡可能獨立的單元，可以降低風險，減少延遲和錯誤，同時提高產品的可靠性和可維護性。 可協調的 (Negotiable) 為了達到產品開發的效率和靈活性，User Story 必須是可協調的，即可以保留一些開放式描述，讓團隊進行討論和協調。User Story 的開放式描述可以激發團隊成員的討論，進而確定 User Story 的實際需求和功能。同時，開放式描述也可以在開發過程中進行調整和修改，以適應產品開發的實際情況。在 User Story 中保留開放式描述可以幫助團隊在開發期間進行更好的協調和溝通，並確保產品能夠滿足用戶需求。最終，這樣的協調和討論可以幫助團隊建立更強的團隊合作精神，以達成產品開發的最終目標。 有價值的 (Valuable) User Story 對於使用者來說非常重要，因為它們確定了產品的功能和特性，並且能夠滿足用戶的需求。如果 User Story 無法滿足用戶需求，那麼產品將無法被成功接受。為了確保 User Story 的價值，開發團隊必須理解並關注用戶需求，將其轉化為可實現的 User Story。只有這樣，才能創造出一個有價值的產品，並滿足用戶需求。 可預估的 (Estimable) 必須能夠對它們的大小、難易度和所需時間進行預估。這樣可以幫助開發團隊更好地分配工作，同時確保產品交付的準時性和品質。通過對 User Story 進行預估，開發團隊可以更好地掌握開發進度和進度風險，並提前進行調整。但需要注意的是，User Story 的預估並不是一個精確的科學，因為它們可能受到多種因素的影響。因此，開發團隊需要持續進行評估和調整，以確保 User Story 的準確性和可行性，並最終創造出高質量的產品。...

這是我在 .NET Conf Taiwan 2022 的演講 - 那些年用 Azure Boards 交付過的產品 以 5 個痛點來分享之前 Scurm 所遇到的問題，當時怎麼解決， 並將其整理成為文章版更難完整記錄本場的內容 Scrum Guide 說 Product Owner 需要依照價值排好 Backlogs，讓整個團隊可有穩定的節奏開發產品，但怎麼排序往往是個難題，有沒有一個框架可以參考? https://uxdesign.cc/how-to-choose-your-product-prioritization-framework-ff0320d63ebf 的作者製作了一個框架提供參考 可以用兩個面向各字給 1-5 分來決定用哪種價值排序方式 需給客戶驗證的程度: 需要在End User的參與下進行一定程度的數據收集或假設驗證練習來驗證程度，越密切分數越高 定性定量的程度: 需要更多的數據驗證，因素越多分數越高 透過這樣的兩個面向，可以初步選擇所使用的框架，本文以最 MoSCoW 及 WSJF 做舉例 MoSCoW MoSCoW是一種常用的優先順序法，用於將需求和功能分為四個類別： “M” 代表必需品（Must Have），這些功能或需求是關鍵的，必須在產品中實現，否則產品無法正常工作或無法交付。這些功能或需求通常是必要的核心功能或重要的業務需求。以我自己定義通常為 “沒有交付就不能達成商業目標” 的項目 “S” 代表應該品（Should Have），這些功能或需求是非常重要的，但不是必須的。如果有足夠的時間和資源，這些功能或需求應該被優先實現。 “C” 代表願望品（Could Have），這些功能或需求是可選的，通常是增強產品體驗或功能的選項。如果時間和資源允許，可以考慮實現這些功能或需求。 “W” 代表不需要品（Won’t Have），這些功能或需求是不必要的，不需要在產品中實現。這些功能或需求可能已被視為過時或不再需要。 當然，以上可以自己定義，目的為直覺得加速判斷，以我自己定義可以用以下方式來做收斂: Must Have: 沒有交付就不能達成商業目標 Should Have: 重要但短期有替代方案 Could Have: 不做沒關係，但做了能為產品帶來加分效果 Won’t Have: 就算做了有無助於提升產品價值 而 Azure Boards 可以怎麼做?...

Scrum 353 Scrum Inc.創辦人 Jeff Sutherland 在他的書《Scrum: The Art of Doing Twice the Work in Half the Time》中提出的概念，它是 Scrum 框架的一種擴展，旨在幫助團隊更好地應對複雜性和不確定性。 裡面提到有個口訣 Scrum 353 的，它的核心概念是 “三個角色、五個事件、三個交付物”，其中： 三個角色：產品負責人、開發團隊、Scrum Master 五個事件：Sprint、Sprint Planning、Daily Scrum、Sprint Review、Sprint Retrospective 三個工件：產品待辦清單、Sprint待辦清單、增量 在跑 Scrum 一直以來我都是用 Azure DevOps 來完成整個流程，但就像 JIRA 一樣，裝了一些外掛後會讓整個運作更順，此篇文章整理我在實務上推薦必裝的外掛 此文章會不定期更新 價值排序 WSJF (Weighted Shortest Job First backlogs開始跟大海一樣，需要的是更多因素的評估，WSJF是一個考量 PMF 及開發成本的評估方式，此外掛可以自動計算出分數 Tags Manager Tag 維護的好，可以用 Query 產生出更多的報表，此外掛可以用來維護已建立的 Tag Multivalue control 如果想區別單子的Compoment，除了 Tag 外，也可以獨立用這種方式進行分類 SpecMap aka User Story Mapping 如果想跟團隊跑 User Story Mapping 腦力激盪跑出產品方向，這就是在 Azure DevOps 實踐的方式...

前言 在 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，屬於比較大方向的描述...