sprint-velocity-analysis

スプリントベロシティ分析

スプリントのベロシティデータを分析し、エンジニアリングチームの健全性に関する率直なレポートを作成します。目的は、楽観的に見えるグラフを作ることではありません。デリバリーのパターンを明らかにし、機能不全を早期に特定し、チームとマネージャーが実行できる提案を提示することです。ベロシティの傾向（改善、低下、横ばい、不安定）、ストーリーポイントの見積もりの一貫性、慢性的な過剰コミットを示す持ち越しのパターン、キャパシティに関する兆候を確認します。テキスト形式の傾向の可視化、健全性の診断、測定可能な目標を含む具体的な改善提案を作成します。

必須入力

まだ提供されていない場合は、次の情報を尋ねてください。

• スプリント履歴 — 各スプリントについて、スプリント名／番号、コミットしたストーリーポイント、完了したストーリーポイント、次のスプリントに持ち越した項目数。できれば最低6～8スプリント分
• チームの規模と変更 — 現在のチーム規模と、データ対象期間中のメンバーの追加や離脱
• 既知の業務中断要因 — 祝日、全社集会、オンコールインシデント、その他特定のスプリントに影響したイベント
• サイクルタイムデータ（任意） — 利用可能な場合は、スプリントごとのp50およびp90のサイクルタイム（開始から完了までの時間）
• 完了の定義 — このチームにおける「完了」の意味（mainへのマージ、本番環境へのデプロイ、POによる承認など）

サイクルタイムデータが提供されていない場合は、そのセクションを省略し、推奨する追加データソースとして記載してください。

出力形式

---

スプリントベロシティ分析：[チーム名]

分析期間： スプリント[N]～スプリント[N+7]（[日付範囲]） チーム規模： [X人のエンジニア]（[期間中の変更について記載]） レポート日： [日付] データソース： [データの取得元 — Jira、Linear、スプレッドシートなど]

---

ベロシティの傾向

生データ

スプリント	コミット済み	完了	完了率	持ち越し	備考
[スプリントN]	[Xポイント]	[Xポイント]	[X%]	[Xポイント／X項目]	[業務中断要因または背景]
[スプリントN+1]	[Xポイント]	[Xポイント]	[X%]	[Xポイント／X項目]
[スプリントN+2]	[Xポイント]	[Xポイント]	[X%]	[Xポイント／X項目]
[スプリントN+3]	[Xポイント]	[Xポイント]	[X%]	[Xポイント／X項目]
[スプリントN+4]	[Xポイント]	[Xポイント]	[X%]	[Xポイント／X項目]
[スプリントN+5]	[Xポイント]	[Xポイント]	[X%]	[Xポイント／X項目]
[スプリントN+6]	[Xポイント]	[Xポイント]	[X%]	[Xポイント／X項目]
[スプリントN+7]	[Xポイント]	[Xポイント]	[X%]	[Xポイント／X項目]
平均	[Xポイント]	[Xポイント]	[X%]	[Xポイント]

ベロシティチャート（スプリントごとの完了ポイント）

Points
  60 |
  55 |          ●
  50 |    ●           ●
  45 | ●        ●          ●
  40 |               ●          ●
  35 |
  30 |
     +--+--+--+--+--+--+--+--
      N N+1 N+2 N+3 N+4 N+5 N+6 N+7
      Sprint

  ● = Completed points   — = Average ([X pts])

提供された実データを基に、ASCII文字を使ってこのチャートを作成してください。Y軸の範囲はデータに合わせて調整してください。コミット済みではなく、完了したポイントをプロットしてください。平均値は破線で示してください。

傾向の診断

指標	値	解釈
平均ベロシティ	[Xポイント／スプリント]	[計画の基準値]
ベロシティの標準偏差	[±Xポイント]	[平均の15%未満＝安定、25%超＝不安定]
傾向の方向	[改善／横ばい／低下／不安定]	[直近3スプリントの平均と、先行する3スプリントの平均を比較]
平均完了率	[X%]	[健全：80～95%、75%未満＝慢性的な過剰コミット]
持ち越し率	[コミット済みポイントのうち、スプリントごとに持ち越される割合：X%]	[健全：15%未満、25%超＝システム上の問題]
完了率が75%未満のスプリント	[8スプリント中X回]	[8回中3回超＝一時的なばらつきではなく、構造的な問題]

---

ストーリーポイントの調整

ストーリーポイントが役立つのは、一貫して適用されている場合に限られます。データに次の調整シグナルがないか確認してください。

シグナル	観測結果	解釈
チーム規模が安定しているにもかかわらず、ベロシティのばらつきが大きい	[はい / いいえ]	見積もりに一貫性がないことを示唆します。同じ作業量でも週ごとに異なるポイントが付けられています
継続的なコミット過多（コミット済み >> 完了）	[はい / いいえ — スプリントあたり平均 X ポイント]	チームが見積もりに余裕を持たせすぎているか、過去のキャパシティを考慮していません
継続的なコミット不足（完了 >> コミット済みが 20% 超）	[はい / いいえ]	チームが見積もりに過剰な余裕を持たせているか、計画外の作業を頻繁に取り込んでいます
持ち越しに大きな項目（> 13 ポイント）が頻繁に含まれる	[はい / いいえ]	項目が大きすぎて信頼できる見積もりができていません。より適切な分解が必要です
チーム変更後のベロシティ急落	[はい / いいえ — スプリント N+X]	チーム構成の変更後、チームがキャパシティを再調整していません

調整の判定： [適切に調整済み / 再調整が必要 / 調整が著しく不適切 — 上記のシグナルに基づく説明を一文で記載]

再調整が必要な場合： [具体的な推奨事項 — 例：「直近の完了済み項目 20 件を使って調整セッションを実施し、チームで再採点したうえで、得られた相対的なサイズを今後の見積もりの基準にしてください。」]

---

持ち越しパターンの分析

持ち越しは、コミットメントの信頼性に問題があることを示す最も信頼性の高い先行指標です。

スプリント	持ち越された項目	持ち越しに共通するテーマ
[スプリント N]	[X 項目 / X ポイント]	[技術的負債、依存関係によるブロック、スコープ設定の誤りなど]
[スプリント N+1]	[X 項目 / X ポイント]	[テーマ]
[スプリント N+2]	[X 項目 / X ポイント]	[テーマ]

特定された持ち越しの根本原因：

• [根本原因 1：例：「持ち越し 12 件中 5 件はサードパーティ API 連携が原因でブロックされていました。見積もりの失敗ではなく、外部依存関係によるものです」]
• [根本原因 2：例：「持ち越し 12 件中 4 件は 8 ポイント以上と見積もられていたものの、後から想定の 2～3 倍の規模だと判明した項目でした」]
• [根本原因 3：例：「持ち越し 12 件中 3 件は、オンコールインシデントによる割り込みで、計画外のキャパシティが消費されたことが原因でした」]

---

キャパシティ利用率

スプリント	チーム規模	利用可能なキャパシティ（ポイント）	コミット済み	利用率 %	混乱要因
[スプリント N]	[X 人のエンジニア]	[X ポイント]	[X ポイント]	[X%]	[休暇 / インシデント / なし]
[スプリント N+1]	[X 人のエンジニア]	[X ポイント]	[X ポイント]	[X%]

使用したキャパシティ計算式： [X 人のエンジニア × 1 人あたり Y ポイント / スプリント = 利用可能な Z ポイント。調整：対象期間中にチームのキャパシティが変わった場合、各チーム規模を適用したスプリントを記載してください。]

平均利用率： [X%] 利用率の解釈： [< 70% = チームの負荷が低い、または見積もりに過剰な余裕を持たせている | 70～90% = 健全な範囲 | > 90% = 計画外の作業に対応する余裕がなく、脆弱]

---

健全性の診断

項目	スコア	根拠	優先度
デリバリーの予測可能性	[緑 / 黄 / 赤]	[平均完了率 X%、標準偏差 Y ポイント]	[高 / 中 / 低]
コミットメントの正確性	[緑 / 黄 / 赤]	[チームはスプリントあたり平均 X ポイント過剰にコミット]
見積もりの一貫性	[緑 / 黄 / 赤]	[ベロシティの標準偏差 ±X ポイント、調整の判定]
持ち越しの管理	[緑 / 黄 / 赤]	[持ち越し率 X%、根本原因]
キャパシティ管理	[緑 / 黄 / 赤]	[平均利用率 X%、混乱要因への対応]
トレンドの方向性	[緑 / 黄 / 赤]	[直近 3 スプリントの平均と、その前の 3 スプリントの平均の比較]

スコアの目安： 緑 = 健全な範囲内で稼働しています。黄 = 境界的です。注意深く見守るか、単一スプリントの異常として扱ってください。赤 = 慢性的な問題があり、積極的な介入が必要です。

全体的な健全性： [緑 / 黄 / 赤] — [一文で要約：「チームはスプリントあたり X ポイントを安定してデリバリーしていますが、慢性的なコミット過多が士気を損ない、ステークホルダーに誤解を招く状況を生み出しています。」]

---

ブロッカーの頻度分析

ブロッカーデータが提供されている場合は、このセクションを記入してください。提供されていない場合は、追跡項目として追加することを推奨する旨を記してください。

ブロッカーのカテゴリ	頻度（直近8スプリント）	ブロックされた平均日数	影響（遅延したポイント数）
外部依存関係	[X occurrences]	[X days]	[X pts]
技術的負債／手戻り	[X occurrences]	[X days]	[X pts]
要件の不明確さ	[X occurrences]	[X days]	[X pts]
オンコールによる中断	[X occurrences]	[X days]	[X pts]
環境／ツール	[X occurrences]	[X days]	[X pts]

対処すべき最優先のブロッカー： [最も影響の大きいブロッカーのカテゴリを1つ挙げ、それに対処することでベロシティがどう向上するかを説明してください。]

---

改善の推奨事項

期待される影響の大きい順に、具体的な推奨事項を3つ提示してください。各推奨事項には、測定可能な成功目標と実施手順を含めてください。

推奨事項1：[タイトル]

対処する問題： [Red または Yellow の健全性指標と、データが示す内容]

実施内容：

1. [具体的なアクション — テックリードが担当者を割り当てられるほど具体的に記載]
2. [次の手順]
3. [次の手順]

担当者： [テックリード／エンジニアリングマネージャー／チーム全体] 開始時期： [今スプリント／次のスプリント／2週間以内]

測定可能な目標： [例：「3スプリント以内に持ち越し率を15％未満にする」または「4スプリント連続で完了率を80％超にする」]

効果を確認する方法： [成果指標の改善に先行して確認できる指標 — 例：「目標達成前から、持ち越し項目がスプリントごとに減少している」]

---

推奨事項2：[タイトル]

対処する問題： [健全性指標と根拠]

実施内容：

1. [手順]
2. [手順]
3. [手順]

担当者： [役割] 開始時期： [時期]

測定可能な目標： [具体的な指標と期間]

効果を確認する方法： [先行指標]

---

推奨事項3：[タイトル]

対処する問題： [健全性指標と根拠]

実施内容：

1. [手順]
2. [手順]

担当者： [役割] 開始時期： [時期]

測定可能な目標： [具体的な指標と期間]

効果を確認する方法： [先行指標]

---

次のスプリントのキャパシティ予測

次のスプリント： [Sprint N+8] 既知のチーム規模： [X engineers] 既知のキャパシティ減少要因： [休暇：合計X日、オンコールローテーション：予定外のキャパシティを約Y pts消費、など]

要因	影響
基本キャパシティ（過去の平均）	[X pts]
休暇／予定された不在	−[X pts]
オンコールの負荷（推定）	−[X pts]
Sprint [N+7] からの持ち越し	+[X pts committed capacity already spoken for]
推奨コミットメント上限	[X pts]

確度： [高 — チームが安定しており、キャパシティが把握できている | 中 — 中断の程度に不確実性がある | 低 — チーム構成が不確実]

計画に関する推奨： [1文で記載 — 例：「Sprint [N+8] の上限をX ptsとして計画してください。持ち越し項目を踏まえ、新たなスコープを追加する前に、まずそれらの完了を優先してください。」]

---

サイクルタイムの分布（データが提供されている場合）

スプリント	p50 サイクルタイム	p90 サイクルタイム	完了項目数
[Sprint N]	[X days]	[X days]	[X items]
[平均]	[X days]	[X days]

サイクルタイムの解釈： [p90 が p50 の2倍を超える場合は、調査が必要な、長期間停滞している項目が存在することを示します。p50 が時間とともに増加している場合は、ストーリーポイントの変更とは無関係にスループットが低下していることを示します。]

サイクルタイムのデータが提供されていない場合：この分析にはサイクルタイムのデータが含まれていません。ストーリーポイントだけでは明らかにならないスループットの問題を検知するため、スプリントごとのp50およびp90サイクルタイムを追跡項目に追加することを推奨します。

---

品質チェック

• ベロシティチャートが、汎用のプレースホルダーチャートではなく、提供された実際のデータから生成されている
• トレンドの診断で方向性（改善／横ばい／低下／不安定）を示し、定量的な根拠（直近の平均とそれ以前の平均の比較）を提示している
• 持ち越しの根本原因を、件数を含む具体的なカテゴリで示している。持ち越しがあるという一般的な所見にとどまっていない
• 3つの各推奨事項に、担当者名、開始日、期限を伴う測定可能な目標が含まれている
• 次のスプリントのキャパシティ予測で、過去の平均を基準値として使用し、既知の減少要因を具体的に差し引いている
• 健全性診断表で、根拠欄に根拠を明記したうえで赤／黄／緑を使用している。裏付けのない評価はない
• 指標（サイクルタイム、ブロッカーログなど）が不足している場合、レポートで追加を推奨する指標として明示している

アンチパターン

• プレースホルダーデータからベロシティチャートを生成しないでください。提供された実際のスプリントデータを反映させる必要があります
• 直近の平均とそれ以前の平均を計算せずに、トレンドの方向性を診断しないでください。「低下しているように見える」は診断ではありません
• 持ち越しについて一般的な所見だけを挙げないでください。分析を実行に移せるよう、根本原因のカテゴリと件数を特定してください
• 担当者名、開始日、測定可能な目標を含まない推奨事項を作成しないでください
• 根拠欄に根拠を明記せずに、健全性の各側面を評価しないでください。裏付けのない赤／黄／緑の評価には信頼性がありません