sprint-retrospective

スプリントのふりかえり

完了した作業を1つのふりかえり形式、少数のテーマ、担当者が明確なフォローアップアクション数件にまとめる場合に、このスキルを使用します。

特殊なケースに対応する場合や、依頼の範囲が広がり始めた場合は、次のリファレンスを確認してください。

• references/facilitation-modes.md
• references/action-review-and-packet-shapes.md

このスキルを使用する場合

• スプリント、リリースの一部、マイルストーン、または困難だったイテレーションの完了後に、スプリントのふりかえりを行う
• リモート、ハイブリッド、または部門横断チームのふりかえりを進行する
• 繰り返されるチームの不満を、具体的なプロセス実験にまとめる
• ふりかえりのアクションが完了、停滞、ブロック中、または取り下げる価値があるかを確認する
• 使い古されたテンプレートを再利用せず、より適切なふりかえり形式を選ぶ
• ワークフローから学ぶことを重視し、技術的な根本原因分析を深掘りしない、ソフトウェア、プロダクト、マーケティング、オペレーション、ゲームチームのマイルストーンに関するポストモーテムを行う

このスキルを使用しない場合

• 実際のタスクが、次に行う作業の計画、作業の分割、または次のスプリントの準備である場合 → task-planning を使用します
• 実際のタスクが、作業量、キャパシティ、自信度、または規模の見積もりに関する意見の相違である場合 → task-estimation を使用します
• 実際のタスクが、デイリーシンク、ボードの確認、またはブロッカーを優先するステータス確認の儀式である場合 → standup-meeting を使用します
• 主なタスクが、障害のフォレンジック調査、セキュリティ調査、または詳細なインシデント分析である場合 → デバッグ／インシデント／ローンチ固有のスキルを使用し、プロセスのフォローアップを行う場合にのみここへ戻ります

手順

ステップ 1：依頼内容を整理する

形式を提案する前に、依頼を分類します。

retro_intake:
  cadence: sprint | release | milestone | project-phase | mixed | unclear
  team_shape: colocated | hybrid | distributed | cross-functional | unknown
  current_pain:
    - stale-format
    - low-participation
    - blame-risk
    - too-many-actions
    - no-follow-through
    - remote-friction
    - weak-evidence
    - recurring-same-problems
    - unclear
  evidence_available:
    - previous-actions
    - board-notes
    - ticket-summary
    - metrics
    - customer-feedback
    - playtest-feedback
    - none
  facilitation_need: light | medium | high
  psychological_safety: low | medium | high | unknown
  desired_outcome:
    - identify-themes
    - choose-experiments
    - repair-ritual
    - capture-postmortem-learnings
    - review-old-actions

次に、主要な形式を必ず1つ選択します。

• live-facilitated-retro
• async-first-retro
• hybrid-retro
• milestone-postmortem
• action-review-reset

ステップ 2：要件に合う最小限の形式を選ぶ

references/facilitation-modes.md を参照し、ワークフローに適合する最も簡素な形式を選びます。

デフォルトのルール：

• 分散チームまたはタイムゾーンにばらつきがある → async-first-retro を優先します
• リモート参加者と対面参加者が混在する → hybrid-retro を優先します
• リリース／デモ／ローンチ／垂直スライスから学ぶ → milestone-postmortem を優先します
• アクションアイテムが放置されることが主な失敗要因である → action-review-reset を優先します
• それ以外の場合は live-facilitated-retro を選びます

複数の主要な形式を1つの回答に混在させないでください。

ステップ 3：根拠と過去のコミットメントから始める

新たな所見を作成する前に、すでに起きたことを必ず確認します。

最低限の確認項目：

• 前回のふりかえりのアクション：完了 | 停滞 | ブロック中 | 取り下げ
• スプリントまたはマイルストーンの結果
• 持ち越し作業、ブロッカー、または繰り返し発生した中断
• 特筆すべきQAの急増、ローンチ時の摩擦、顧客からのフィードバック、またはプレイテストのフィードバック
• 入手可能であれば、直近2～3回のふりかえりで繰り返されたテーマ

ルール：

• 過去のアクションが見つからない場合は、そのことを明示します
• チームが多くのアクションを挙げても、どれも完了しない状態が続いている場合は、action-review-reset に切り替えます
• 根拠が乏しい場合は、確実であるかのように装わず、結果の確信度が低いと明記します

ステップ 4：非難の場にせず、所見を集める

選択した形式に合うプロンプトのグループを1つ使用します。

適切なグループ：

• うまくいったこと／うまくいかなかったこと／次に変えること
• 始める／やめる／続ける
• 腹が立ったこと／悲しかったこと／うれしかったこと
• 4Ls
• 品質、コミュニケーション、引き継ぎ、デリバリーリスク、またはリリース準備に関連するカスタムプロンプト

留意事項：

• 信頼関係が弱い場合や、一部の参加者が発言を独占している場合は、個別の書き出しや非同期での収集を使用します
• クラスタリングが終わるまでは、所見と解決策の提案を分けておきます
• マイルストーンやゲームのふりかえりでは、パイプライン上の摩擦、QAのタイミング、アセットやコンテンツへの依存関係、プレイテストから得た兆候、リリース準備に関するプロンプトを含めます

ステップ 5：テーマをまとめ、アクション数を絞る

メモを集めたら：

1. 重複を統合します
2. テーマを最大 3～5 件にまとめます
3. チームで対応できる課題と、エスカレーションが必要な課題を分けます
4. テーマに優先順位を付けます
5. アクションを最大 1～3 件選びます

各アクションには、次の項目が必要です。

• 担当者
• 期限、次のスプリント、またはチェックポイント
• 成功の指標
• チームだけでは解決できない場合、エスカレーションであることを明記

ステップ 6：ふりかえりの概要を作成する

一般的なアジャイルの解説ではなく、簡潔な概要を返します。

# Retrospective Brief

## Recommended mode
- Mode: live-facilitated-retro | async-first-retro | hybrid-retro | milestone-postmortem | action-review-reset
- Why this mode fits: ...

## Review of previous actions
| Action | Status | What happened | Keep / close / escalate |
|--------|--------|---------------|--------------------------|
| ... | done/stale/blocked/dropped | ... | ... |

## Evidence considered
- ...

## Top themes
1. ...
2. ...
3. ...

## Facilitation flow
1. ...
2. ...
3. ...
4. ...

## Prompt set
```text
...

合意したアクション

アクション	担当者	期限	成功の指標
...	...	...	...

リスク／エスカレーション

• ...

関連する引き継ぎ

• task-planning は、...の場合に使用します
• task-estimation は、...の場合に使用します
• standup-meeting は、...の場合に使用します

### Step 7: Tailor the brief to the mode
Use `references/action-review-and-packet-shapes.md` for stable packet patterns.

Mode-specific reminders:
- **live-facilitated-retro** — timebox discussion and use silent writing first if louder voices dominate
- **async-first-retro** — collect notes in a bounded window, then reserve the live step for clarification and prioritization only
- **hybrid-retro** — make the shared board/doc the primary workspace so remote participants do not get outrun by room talk
- **milestone-postmortem** — include quality, handoffs, readiness, and cross-discipline coordination prompts without drifting into full RCA
- **action-review-reset** — spend the first half on prior commitments and why they failed before collecting anything new

### Step 8: Route adjacent PM work explicitly
Before finalizing, state when the user should switch skills:
- use `task-planning` for next-sprint decomposition, backlog cleanup, or scope slicing
- use `task-estimation` for sizing, confidence, or capacity disagreements
- use `standup-meeting` when the right next move is a lighter daily coordination change

## Output format
Always return a **Retrospective Brief** with these qualities:
- exactly one primary mode
- previous-action review before new action creation
- 3-5 themes maximum
- 1-3 owned actions maximum
- clear distinction between team-owned actions and escalations
- explicit PM-cluster handoffs when the job changes

## Examples

### Example 1: remote team stuck in stale retros
**Input**
> Our sprint retros are the same every two weeks and people barely talk. We’re remote across three time zones.

**Output sketch**
- Mode: `async-first-retro`
- Silent/async collection window before the meeting
- Short live clustering and vote
- 1-2 actions with explicit owner and next-retro review

### Example 2: game milestone postmortem
**Input**
> We just finished a demo milestone for our Unity game. QA found issues late, art handoffs slipped, and the team is frustrated.

**Output sketch**
- Mode: `milestone-postmortem`
- Prompts include handoffs, asset readiness, QA timing, and cross-discipline blockers
- Actions split between team-owned workflow experiments and producer escalations

### Example 3: same action items keep dying
**Input**
> Every retro ends with five good ideas and none of them ever happen.

**Output sketch**
- Mode: `action-review-reset`
- First section audits prior actions
- New action count capped at 1-2
- Notes why prior actions failed and what review hook changes next cycle

## Best practices
1. **Start with prior commitments** — otherwise the retro becomes performative novelty.
2. **Pick the smallest mode that fits** — more templates is not the same as better learning.
3. **Keep action counts brutally small** — a few owned changes beat a wall of wishes.
4. **Preserve non-blame framing** — process reflection dies when people feel individually judged.
5. **Use evidence, not memory theater** — bring sprint outcomes, QA spikes, support load, launch friction, or playtest signal when available.
6. **Route out when the job changes** — planning, sizing, and daily-sync redesign are adjacent jobs, not retro substeps.

## References
- Atlassian Team Playbook, *Retrospective* — https://www.atlassian.com/team-playbook/plays/retrospective
- Scrum.org, *What is a Sprint Retrospective?* — https://www.scrum.org/resources/what-is-a-sprint-retrospective
- Miro, *Remote Retrospective Guide* — https://miro.com/agile/guide-to-remote-retrospectives/
- Parabol, *22 Retrospective Ideas for Ambitious Teams* — https://www.parabol.co/resources/sprint-retrospective-ideas/
- TeamRetro, *Sprint Retrospective Template* — https://ww2.teamretro.com/retro-template/sprint-retrospective/