用 Claude Code Skill 來理解 AI 如何協助 Scrum Master
Scrum Master 該怎麼透過 AI 放大自己的工作能力？
這次不先談理論，來直接回頭看一個在 GitHub 上相當受關注的 Claude Code Skill 專案，並以其中的 Scrum Master Skill 為例，看看別人是怎麼把 AI 設計成能實際協助 Scrum 團隊開發的工作工具。
Skill 的基本概念與定位
這個 Claude Code Skill 可以先視為一個專門分析 Sprint 的工具。
它不負責管理專案，也不會自動做決策，而是接收一份結構化的 Sprint 資料，協助整理目前的狀態與可能的問題。
Scrum Master 原本就經常要把分散在各種工具裡的資訊整理起來，讓團隊看清楚現在的進展與風險。這個 Skill 的作用，就是把這段整理與分析的工作標準化。
也就是說，它處理的仍是 Scrum Master 原本就在做的事，只是改用一套更一致的方式來完成。
輸入與輸出：從 Sprint 資料到決策建議
這個 Skill 的使用方式其實很單純，就是透過一份 Sprint 的記錄數據，輸出一段分析結果。
輸入內容會包含 Sprint 的歷史資料，例如任務完成情況、估點與實際交付狀態等。這些資料本來就存在，只是平常可能分散在不同地方。
Skill 會先讀取這些資料，進行整理與計算，再轉成幾個容易理解的重點，例如交付節奏是否穩定、是否出現異常變化，或某些模式是否持續重複出現。
最後，它會再把這些結果進一步整理成可供討論的建議，讓分析不會停留在原始數據層次。
核心概念：用數據取代主觀判斷
在沒有這類工具的情況下，Scrum Master 多半是依據經驗來判斷狀況。
例如會感覺某個 Sprint 較為混亂，或是某些任務反覆延遲。這些判斷通常有其依據，但呈現方式較為零散，也不容易被團隊其他成員理解或驗證。
這個 Skill 的做法，是把這些原本偏向直覺的判斷，轉換成具體的數據表現。
例如交付速度的變化、完成比例的波動，以及未完成工作的累積情況。當這些指標被整理出來，團隊在討論時就能建立共同的參考基準。
這不會讓判斷變成完全客觀，但能讓討論更具體，也更容易聚焦在實際問題上。
AI 幫助看見變化，而不是直接給答案
從這個 Skill 來看，AI 負責的事情其實很明確。
它負責整理資料、找出模式，並把結果轉成容易理解的內容，但不會直接決定接下來該怎麼做，也不會取代 Scrum Master 的判斷。
更貼切地說，它是在協助把原本不容易看見的變化提早整理出來，讓團隊有機會更早發現問題。
這個 Skill 在做什麼：三個核心分析能力
Velocity 分析：掌握交付能力與變化趨勢
這個 Skill 會先從 Velocity 著手，整理每個 Sprint 的完成點數，觀察交付能力的變化。
單看某一次 Sprint 的數字，參考價值其實不高，真正值得注意的是一段時間內的趨勢，例如是否持續上升、開始波動，或出現明顯下滑。
Scrum Master 平常也會看這些數據，但很多時候仍停留在「這次比較多、上次比較少」的直觀判斷。
這個 Skill 進一步做的，是把這些變化整理出來，讓趨勢更清楚。
當交付能力開始變得不穩定時，這些訊號往往會先反映在數據上。越早看見這些變化，就越有機會在進度真正出現延誤之前先做調整。
Sprint 健康度評估：辨識交付是否穩定
除了交付量，這個 Skill 也會評估 Sprint 的整體健康度。
它會觀察完成比例、未完成工作的累積情況，以及任務是否經常跨 Sprint 延續。這些指標能反映團隊的節奏是否穩定。
例如，完成率長期偏低，代表規劃與實際執行之間存在落差。未完成工作持續累積，則表示負載過高，或優先順序沒有釐清。
這些問題在日常開發中不一定會立刻被注意到，但當它們被整理成一致的指標後，就會更容易被看見，也更容易成為團隊討論的基礎。
Retrospective 分析：追蹤改善是否發生
這個 Skill 也會把回顧會中提出的改善項目，與後續 Sprint 的結果放在一起對照。
在實務上，團隊常會在 Retrospective 中提出改進方向，但過了幾個 Sprint 之後，往往很難確認這些調整是否真的帶來效果。
透過資料比對，這個 Skill 會嘗試找出某些改善行動發生之後，相關指標是否出現變化，例如交付是否變得更穩定，或某一類問題是否減少。
這也讓回顧不再只是各憑感覺的討論，而是變成一個可以持續驗證的過程。
Skill 的核心在於把「感覺」轉成「可觀察的訊號」
從這三個分析能力來看，這個 Skill 並沒有引入複雜的機制。
它的核心是把實際發生的資料整理起來，轉換成幾個可以持續觀察的訊號，例如交付趨勢、節奏穩定性，以及改善是否發生。
當這些訊號被固定下來，團隊在討論時就不再完全依賴個人經驗，也更容易建立一致的理解。
Skill 的運作方式：從資料到決策的流程
Sprint 歷史資料包含哪些關鍵資訊
使用這個 Skill 的前提，是先準備一份從 Jira 或其他 Issue Tracking 系統匯出的 sprint_data.json。由於後續會交由 Python 工具處理，因此資料格式需要符合既定結構，不能任意調整。
{
"team_info": { "name": "string", "size": "number", "scrum_master": "string" },
"sprints": [
{
"sprint_number": "number",
"planned_points": "number",
"completed_points": "number",
"stories": [...],
"blockers": [...],
"ceremonies": {...}
}
],
"retrospectives": [
{
"sprint_number": "number",
"went_well": ["string"],
"to_improve": ["string"],
"action_items": [...]
}
]
}資料主要分成三塊：team_info、sprints、retrospectives。也就是說，它需要拿到團隊基本資訊、每個 Sprint 的執行狀況，以及 Retrospective 會議的紀錄。
例如在 sprints 裡，可以看到像這樣的內容：
{
"sprint_number": 1,
"sprint_name": "Sprint Alpha",
"planned_points": 23,
"completed_points": 18,
"added_points": 3,
"removed_points": 2,
"carry_over_points": 5,
"team_capacity": 40,
"working_days": 10,
"team_size": 5
}這一段已經包含一個 Sprint 的幾個關鍵面向了：一開始規劃多少故事點數、最後完成多少，中途有沒有變動，還有工作被帶到下一個 Sprint 的情況。
再往下看 stories：
{
"id": "US-104",
"title": "Advanced filtering options",
"points": 5,
"status": "in_progress",
"blocked_days": 2,
"priority": "low"
}這裡可以看到單一工作的狀態、點數，以及卡住了多久。也就是說，這讓 Skill 不只看得到最終結果，還能往下追出是哪一類工作出了問題。
另外，像 blockers 和 ceremonies 這些欄位，也把阻礙事項與團隊運作狀況一起納入。換句話說，資料本身已經先把 Scrum Master 平常會關注的幾個面向整理進來了。
透過 Python 工具進行資料分析的流程
有了這些資料之後，Skill 不會直接生成一段結論，而是先用 Python 讀取 sprint_data.json，再把資料拆成三個分析方向：交付速度、Sprint 健康度，以及回顧改善狀況。
先看 Sprint 層級的資料，例如這一段：
{
"planned_points": 24,
"completed_points": 19,
"carry_over_points": 5,
"team_capacity": 42
}這些欄位會先交給 velocity_analyzer.py 做第一層計算。它會根據 planned_points、completed_points、added_points、removed_points、carry_over_points 這些欄位，算出每個 Sprint 的 velocity、完成率，以及 scope 變動比例。
接著，程式會把多個 Sprint 放在一起比較，計算平均值、中位數、最大值、最小值與 rolling average。再往下，會以最近幾個 Sprint 做線性回歸，判斷目前的交付趨勢是穩定、改善，還是下降，同時用標準差與平均值的比例衡量波動程度，並透過 z-score 找出異常值。
最後，它還會透過蒙地卡羅方法，模擬未來幾個 Sprint 可能的交付範圍，輸出不同信心水準下的預測結果。
看到這裡，能理解的主要還是交付節奏本身，但還無法進一步判斷問題可能出在哪裡。因此，Skill 接著會繼續往下讀取工作項目與阻礙相關資料。
例如 stories 裡會有這樣的內容：
{
"id": "US-104",
"title": "Advanced filtering options",
"points": 5,
"status": "in_progress",
"blocked_days": 2,
"priority": "low"
}而 blockers 裡則有像這樣的資料：
{
"description": "WebSocket library compatibility issue",
"resolution_days": 4,
"category": "technical"
}這些資料會再交給 sprint_health_scorer.py 處理。它不只看點數有沒有完成，而是把 Sprint 的健康度拆成幾個面向一起評估，包括規劃與實際完成的差距、scope 是否穩定、blocker 平均花多久排除、story 的完成分布，以及 velocity 是否具備可預測性。
這些面向各自都有對應的分數與權重，最後再合併成一個整體健康分數。這樣一來，Scrum Master 看到的就不只是 Sprint 好不好，還能進一步知道是哪些面向拉低了整體狀況。
再往下，Skill 也會讀 Scrum 儀式會議與回顧資料。
例如 ceremonies 裡有這樣的內容：
{
"attendance_rate": 0.88,
"engagement_score": 0.82
}而 retrospectives 裡則有像這樣的資料：
{
"to_improve": [
"Daily standup engagement dropped this sprint"
],
"action_items": [
{
"description": "Schedule technical spike sessions before Sprint Planning",
"status": "completed"
}
]
}這一部分會交給 retrospective_analyzer.py 處理。它會統整每次 Retrospective 提出的改善項目，計算 action item 的完成率、平均完成時間，以及是否存在逾期仍未完成的項目。
同時，它也會把 went_well 和 to_improve 裡的文字做主題分類，例如流程、技術、溝通或團隊互動，藉此觀察哪些問題持續反覆出現。
除此之外，它還會追蹤幾個 Sprint 之間的變化，例如每次回顧提出多少 action item、完成率是否下降，以及回顧品質是否下滑。
這讓分析不只停留在「發生了什麼」，也能進一步看到「前面提出要改善的事，後來有沒有真的做到」。
把這三支腳本放在一起看，整個分析流程其實很清楚。velocity_analyzer.py 先處理交付速度與趨勢，sprint_health_scorer.py 接著評估 Sprint 的整體運作是否穩定，最後再由 retrospective_analyzer.py 檢查改善行動是否持續發生。
這三段剛好對應 Scrum Master 平常最在意的三個面向：交付節奏、執行狀況，以及改善成效。
差別只在於，原本這些事情大多要靠人工自己翻資料、比對與計算，現在則交由 Python 依固定邏輯一次處理完成。
這讓分析不必每次重新做一遍，而是變成一個可以反覆執行、持續比較的流程。
從資料處理到產出建議的邏輯
當這三個分析結果都產生之後，Skill 才會把它們整理成可閱讀的內容。
整體順序會是先描述現象，再整理出模式，最後才延伸成建議。
例如交付速度維持穩定，但 scope 變動偏高。或是 blocker 排除時間偏長，同時回顧會的行動項目完成率又下降。
這些訊號會被放在一起看，讓 Scrum Master 看到的是一個較完整的狀況，而不是單一指標。
這裡有一個關鍵點：Skill 不會直接告訴你接下來應該怎麼做，它只是把資料中的變化整理出來。最後要如何判斷，仍然要回到團隊當下的脈絡。
AI 並不是憑空判斷，而是基於結構化資料推論
把整個流程串起來看，其實就是三個步驟。
- 先把 Sprint、工作項目、阻礙與回顧資料整理成固定格式。
- 再用三支腳本分別分析交付、健康度與改善機制。
- 最後把分析結果整理成可以拿來討論的內容。
AI 在這裡做的事，是把原本需要人工整理與計算的過程固定下來，讓每一次分析都從同一個基準開始。
Scrum Master 仍然要負責判斷與引導，但在進入討論之前，已經先有一組較清楚的依據可供參考。
建議將資料餵給 Claude 或其他 LLM 之前，需進行去識別化（De-identification）。例如移除開發者真實姓名、特定客戶名稱或機密專案代號，改用代號代替，以避免內部資料被 AI 做為訓練資料後就公開了。
蒙地卡羅模擬的準確性極度依賴「歷史樣本數」，團隊至少需要累積 3-5 個 Sprint 以上的穩定資料，模擬結果才具有統計意義。如果團隊正處於大幅變動期（如人員更換、技術棧轉型），AI 的預測可能會失效。
Scrum Master 如何實際使用這個 Skill
在 Sprint Planning 中用預測輔助估算與承諾
在 Sprint Planning 前，Scrum Master 可以先用這個 Skill 分析最近幾個 Sprint 的資料。
先看平均交付量、波動程度，以及未來幾個 Sprint 的預測區間。這裡的重點，不是拿到一個看似精準的數字，而是先看一個較合理的範圍。
例如，若預測結果顯示多數情境都落在某個區間內，就可以用這個區間來討論這次 Sprint 的承諾是否合理。
若分析結果也顯示過去幾個 Sprint 的 scope 變動偏高，Scrum Master 就能提前提醒團隊，這次規劃需要更保守一些。
這樣一來，Planning 的討論就會有一個共同的參考點，而不是完全依賴直覺或單一數字。
在 Daily 與過程中用數據觀察風險變化
在 Sprint 進行中，這個 Skill 不需要每天完整執行，但可以在中段或關鍵時點跑一次。
像是 blocker 的解決時間、未完成工作的累積，以及 story 的狀態分布，都會影響 Sprint 的健康度。
如果某個 Sprint 的遺留點數（carry over points）持續偏高，或 blocker 的解決天數（resolution days）拉長，代表風險正在累積。
這些訊號原本就存在於資料中，只是分散在不同欄位。透過 Skill 整理之後，Scrum Master 會更容易在 Daily 或日常討論中，把這些變化具體提出來，而不是等到 Sprint 結束才回頭檢視。
在 Retrospective 中驗證改善是否有效
因為這個 Skill 分析的資料，本質上都屬於過去累積下來的落後指標，所以它在 Retrospective 的使用價值會更明顯。
Skill 會把每個 Sprint 的行動項目（Action items）統整起來，計算完成率、平均完成時間，以及是否存在逾期未完成的項目。
它也會把待改善（To improve）裡的內容做主題分類，找出哪些問題持續反覆出現。
這讓回顧會議可以同時從兩個角度來看：一個是「這次發生了什麼」，另一個是「之前說要改善的事，後來有沒有真的改善」。
例如，當某個主題連續出現在多個 Sprint，或行動項目的完成率持續下降時，這些都能成為討論的起點。比起只靠印象回顧，這種方式會讓改善行動更容易被持續追蹤。
AI 的價值在於支援決策，而不是取代決策
從這幾個使用情境來看，這個 Skill 並沒有改變 Scrum Master 的工作本質。
Planning 仍然需要團隊一起判斷，Daily 仍然需要持續溝通，Retrospective 也還是用來調整工作方式。
真正的差別在於，原本需要花不少時間整理與比對的資料，現在可以更快被整理出來。Scrum Master 因此能把更多注意力放在引導討論與做出判斷，而不是停留在資料整理本身。
導入 AI 後對 Scrum Master 工作方式的改變
從經驗判斷轉向資料輔助決策
在沒有 AI 協助的情況下，Scrum Master 多半需要先從各種工具中自己整理資料，再依靠經驗判斷目前的狀況。
導入之後，AI 會先把交付、健康度與回顧結果整理出來，原本分散的資訊也會被收斂成一組固定指標。
這帶來的改變，不是讓經驗失去價值，而是讓判斷有了比較一致的起點。
例如看到完成率偏低時，不再只是停留在感覺層次，而是可以回頭對照多個 Sprint 的數據，判斷這究竟是短期波動，還是持續累積的趨勢。
真正的決策仍然需要經驗，但判斷依據會變得更清楚。
從被動發現問題到主動預警
從分析邏輯來看，很多訊號其實都能更早被看見。
例如交付分析會觀察趨勢與波動，當交付開始變得不穩定時，變化會先反映在數據上。
健康度分析則會把 scope 變動、blocker 解決時間與未完成工作等因素一起納入，讓問題不只停留在結果層面。
另外，在回顧分析中，如果行動項目完成率下降，或某些主題持續反覆出現，這些變化也會被整理出來。
這些原本都要靠人工比對不同 Sprint 才看得出來。現在變成固定流程後，就更容易在過程中發現變化，而不是等到交付真的出了問題，才回頭檢討。
從個人觀察到團隊共同理解
過去很多判斷會集中在 Scrum Master 身上，因為資料整理與解讀本來就需要成本。
當分析結果被整理成固定格式後，例如整體健康分數、各面向評估，或是回顧中的主題與行動項目完成率，這些內容就更容易被整個團隊一起理解。
例如看到某個 Sprint 的穩定度偏低，或 blocker 解決時間偏長，這些都能直接成為討論的起點，不必先花時間解釋資料本身。
這樣一來，討論會更聚焦，也更容易形成一致理解。
工作重心會轉向引導與決策品質
從這個 Skill 的運作方式來看，AI 帶來的改變主要集中在兩件事。
- 把資料整理與分析的過程固定下來，降低每次重新整理的成本。
- 讓原本分散在各個工具裡的不同面向資訊，可以被放在一起看。
Scrum Master 的工作並沒有因此變少，但重心會慢慢轉到另一個地方：如何解讀這些結果，以及如何引導團隊做出合適的調整。
換句話說，AI 讓「看見問題」這件事變得更穩定，而「怎麼處理問題」，仍然是 Scrum Master 的責任。
使用 AI 時需要注意的幾個重點
資料品質會直接影響分析結果
這個 Skill 的所有分析，都建立在 sprint_data.json 上。
分析會用到的資料其實很細，例如 planned_points、completed_points、added_points、carry_over_points，以及 stories 裡的 status、blocked_days，甚至 blockers 裡的 resolution_days。
只要這些欄位沒有被正確記錄、資料收集不完整或是收集時間不夠久，後面的分析就會跟著偏掉。
例如：
completed_points沒有準確更新，velocity 就會失真blockers沒有記錄，或沒有填入resolution_days，健康度評估就會偏高，甚至失去參考價值stories的狀態沒有一致標準，完成分布就無法反映真實情況
也就是說，AI 不會自動修正資料品質的問題，它只是把現有資料放大。
資料本身若不穩定，分析結果自然也很難被信任。
過度依賴 AI 可能忽略團隊脈絡
從三支 Python 腳本的邏輯來看，它們做的其實都是規則式分析。
例如：
- 用完成率評估承諾的可靠度
- 用 scope 變動比例判斷穩定性
- 用
resolution_days評估 blocker 的處理情況 - 用關鍵字分類 retrospective 的主題
這些方法可以抓出趨勢，但無法直接理解背後原因。
例如某個 Sprint 的完成率下降，原因可能是需求複雜度提高，也可能是團隊成員變動，甚至是外部依賴導致延遲。這些情境未必會完整記錄在 JSON 裡。
因此，若直接依賴分數或建議，而沒有回到實際情境去理解，很容易做出過度簡化的判斷。
需要搭配實務經驗判讀
這個 Skill 的輸出，本質上是把不同面向的訊號整理出來。
例如在健康度分析的結果中，可能會同時看到整體健康分數不錯，但範圍穩定度偏低，阻礙處理效率也偏慢。
在回顧分析裡，也可能出現團隊成熟度分數很高，但行動項目完成率持續下降的情況。
這些結果不會自動被整合成單一結論，而是先並列呈現出來。
接下來要做的，是由 Scrum Master 判斷這些訊號之間的關係，例如哪些只是短期波動，哪些才是真正需要優先處理的問題。
換句話說，Skill 只能幫忙把資訊整理出來，但不會替你完成取捨與判斷。
另外，AI 在處理數據這類定量資訊時很強，但在理解人類情緒與語境這類定性內容時，仍然有明顯限制。
例如 AI 可能誤判帶有諷刺意味，或寫得過於簡略的紀錄。在回顧分析中，若待改善欄位寫著「進度超棒」，AI 可能會判斷成正面訊號，但實際上也可能是在反諷。
因此，Scrum Master 仍然需要對 AI 整理出的回顧主題進行人工校閱。
AI 提供的是線索，判斷仍在 Scrum Master 身上
這個 Skill 的角色其實很明確，它負責把 Sprint、工作項目、阻礙與回顧資料整理起來，轉成一組可以持續觀察的指標與訊號。
但它不會理解團隊的實際情境，也不會替你決定應該如何調整。
它的價值在於，讓 Scrum Master 能更早看見變化，並以這些線索引導團隊展開討論。
最終的判斷，仍然需要回到團隊本身的脈絡。
結語：使用 AI 的重點在於如何改變工作方式
AI 不只是效率工具，也是決策輔助工具
從這個 Claude Code Skill 的設計來看，它的作用不只是加快資料整理。
三支分析腳本分別處理交付速度、Sprint 健康度與回顧改善狀況，最後再把結果整理成一組可以被理解的訊號。
這代表 AI 的角色，比較接近先把判斷所需的資訊整理出來，而不是直接給出答案。
例如 velocity 的趨勢、範圍變動、blocker 的處理時間，或是行動項目的完成率，這些資訊原本就存在，只是分散在不同地方。
Skill 將它們集中起來，讓決策可以建立在較一致的依據上。
重點在於讓後續判斷有更清楚的基礎，而不是 AI 產出的分析本身。
真正的價值來自持續使用與持續調整
這個 Skill 的價值，不會在第一次使用時就完全顯現。
許多分析需要跨多個 Sprint 才有意義，例如 velocity 的趨勢與波動程度，或 Retrospective 主題是否持續出現。
同樣地，像 action item 的完成率與 blocker 解決時間，也需要累積一段時間，才看得出變化。
也就是說，如果只是偶爾使用一次，結果不一定能反映實際問題。當這些分析被持續使用，才會逐步形成一條可觀察的變化軌跡。
Scrum Master 需要做的，是隨著這些結果持續調整使用方式，而不是固定套用某一組結論。
從小範圍開始導入，通常比較容易落地
從這個 Skill 的運作方式來看，導入門檻其實不在工具本身，而在資料收集與使用習慣。
sprint_data.json 需要維持一致的結構，stories、blockers 與 retrospective 的資料也要被穩定記錄，後續分析才有參考價值。
如果一開始就想全面套用，反而容易卡在資料整理不完整，或流程標準尚未一致。
比較實際的做法，是先選一個使用場景，例如只在 Retrospective 前使用，或先聚焦在 velocity 與健康度分析。等團隊開始習慣用這些結果來討論，再逐步擴展到其他面向。
這樣的節奏，會更容易讓工具融入既有流程。
AI 的影響，最後會反映在團隊的決策與節奏上
AI 並沒有改變 Scrum Master 的核心角色。
需求仍然要被理解，決策仍然要被做出，團隊仍然要被引導。
真正的差別在於，資料整理與分析的過程被固定下來，讓這些決策有了一個較穩定的依據。
當這樣的做法持續發生，團隊能更容易看見變化，也更容易對齊理解。隨著時間累積，影響自然會反映在決策品質與交付節奏上。
