sprint-retrospective

冲刺回顾

当任务是将已完成的工作整理成一种回顾模式、少量主题和几项明确负责人的后续行动时，使用此技能。

遇到特殊情况或请求开始变得复杂时，请先阅读以下参考资料：

• 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

然后准确选择一种主要模式：

• 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

不要在一个回答中混合多种主要模式。

第 3 步：从证据和既有承诺入手

生成新的观察之前，务必先回顾已经发生的事情。

最低限度的检查项：

• 之前的回顾行动：已完成 | 已过时 | 受阻 | 已放弃
• 冲刺或里程碑的结果
• 延续工作、阻碍项或反复出现的中断
• 显著的 QA 问题、上线摩擦、客户反馈或试玩反馈
• 如果有，最近 2-3 次回顾中反复出现的主题

规则：

• 如果缺少之前的行动记录，请明确说明
• 如果团队不断提出许多行动，却没有完成任何一项，请切换到 action-review-reset
• 如果证据不足，请将结果标为低信心，不要假装确定

第 4 步：收集观察，避免把回顾变成相互指责

使用与所选模式相匹配的一组提示词。

适用的提示词组合：

• 进展顺利 / 进展不顺 / 下次改进
• 开始 / 停止 / 继续
• 愤怒 / 悲伤 / 高兴
• 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/