conduct-retrospective
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseConduct a Retrospective
开展回顾会议
Facilitate a structured retrospective that reviews recent project execution, identifies what worked and what didn't, and produces actionable improvement items that feed back into project processes. This skill transforms raw project data into evidence-backed learnings with specific actions, owners, and due dates.
协助开展结构化的回顾会议，复盘近期项目执行情况，识别有效做法与存在问题，并生成可落地的改进项，反哺项目流程。该技能可将原始项目数据转化为有证据支撑的经验总结，包含具体行动、负责人和截止日期。
When to Use
适用场景
- End of a sprint (sprint retrospective)
- End of a project phase or milestone
- After a significant incident, failure, or success
- Quarterly review of ongoing project processes
- Before starting a similar project (lessons learned review)
- 冲刺结束时（冲刺回顾）
- 项目阶段或里程碑完成后
- 重大事件、失败或成功发生后
- 持续项目流程的季度评审
- 启动类似项目前（经验教训复盘）
Inputs
输入信息
- Required: Period under review (sprint number, date range, or milestone)
- Optional: Status reports from the review period
- Optional: Sprint velocity and completion data
- Optional: Previous retrospective actions (to check closure)
- Optional: Team feedback or survey results
- 必填：回顾周期（冲刺编号、日期范围或里程碑）
- 可选：回顾周期内的状态报告
- 可选：冲刺速度与完成数据
- 可选：上一次回顾会议的行动项（用于检查完成情况）
- 可选：团队反馈或调研结果
Procedure
操作流程
Step 1: Gather Retrospective Data
步骤1：收集回顾数据
Read available artifacts from the review period:
- STATUS-REPORT-*.md files for the period
- SPRINT-PLAN.md for planned vs actual
- BACKLOG.md for item flow and cycle times
- Previous RETRO-*.md for open action items
Extract key facts:
- Items planned vs completed
- Velocity trend
- Blockers encountered and resolution time
- Unplanned work that entered the sprint
- Open action items from previous retrospectives
Expected: Data summary with quantitative metrics (velocity, completion %, blocker count).
On failure: If no artifacts exist, base the retrospective on qualitative observations.
读取回顾周期内的可用文档：
- 周期内的STATUS-REPORT-*.md文件
- 用于对比计划与实际执行的SPRINT-PLAN.md
- 用于查看事项流转与周期时长的BACKLOG.md
- 包含未结行动项的往期RETRO-*.md文件
提取关键信息：
- 计划完成与实际完成的事项对比
- 速度趋势
- 遇到的障碍及解决时长
- 冲刺期间新增的非计划工作
- 上一次回顾会议的未结行动项
预期结果：包含量化指标（速度、完成率、障碍数量）的数据汇总。
失败处理：若没有相关文档，则基于定性观察开展回顾。
Step 2: Structure "What Went Well"
步骤2：梳理“工作亮点”
List 3-5 things that worked well, with evidence:
markdown
undefined列出3-5项有效做法，并附上证据：
markdown
undefinedWhat Went Well
工作亮点
| # | Observation | Evidence |
|---|---|---|
| 1 | [Specific positive observation] | [Metric, example, or artifact reference] |
| 2 | [Specific positive observation] | [Metric, example, or artifact reference] |
| 3 | [Specific positive observation] | [Metric, example, or artifact reference] |
Focus on practices to continue, not just outcomes. "Daily standups kept blockers visible" is more actionable than "We delivered on time."
**Expected:** 3-5 evidence-backed positive observations.
**On failure:** If nothing went well, look harder — even small wins matter. At minimum, the team completed the period.| 序号 | 观察结论 | 证据 |
|---|---|---|
| 1 | [具体的正面观察] | [指标、示例或文档参考] |
| 2 | [具体的正面观察] | [指标、示例或文档参考] |
| 3 | [具体的正面观察] | [指标、示例或文档参考] |
聚焦可延续的实践，而非仅关注结果。比如“每日站会让障碍及时可见”比“我们按时交付”更具指导性。
**预期结果**：3-5项有证据支撑的正面观察结论。
**失败处理**：若团队认为没有亮点，需进一步挖掘——即使微小的成果也值得肯定。至少团队完成了本周期的工作。Step 3: Structure "What Needs Improvement"
步骤3：梳理“待改进点”
List 3-5 things that need improvement, with evidence:
markdown
undefined列出3-5项待改进事项，并附上证据与影响：
markdown
undefinedWhat Needs Improvement
待改进点
| # | Observation | Evidence | Impact |
|---|---|---|---|
| 1 | [Specific issue] | [Metric, example, or incident] | [Effect on delivery] |
| 2 | [Specific issue] | [Metric, example, or incident] | [Effect on delivery] |
| 3 | [Specific issue] | [Metric, example, or incident] | [Effect on delivery] |
Be specific and factual. "Estimation was off" is vague. "3 of 5 items exceeded estimates by >50%, adding 8 unplanned days" is actionable.
**Expected:** 3-5 evidence-backed improvement areas with stated impact.
**On failure:** If the team claims everything is fine, compare planned vs actual metrics — gaps reveal issues.| 序号 | 观察结论 | 证据 | 对交付的影响 |
|---|---|---|---|
| 1 | [具体问题] | [指标、示例或事件] | [对交付的影响描述] |
| 2 | [具体问题] | [指标、示例或事件] | [对交付的影响描述] |
| 3 | [具体问题] | [指标、示例或事件] | [对交付的影响描述] |
内容需具体且基于事实。“估算不准确”过于模糊，而“5项事项中有3项的实际耗时超出估算50%以上，增加了8天非计划工时”则更具可操作性。
**预期结果**：3-5项有证据支撑的待改进领域，并说明其影响。
**失败处理**：若团队声称一切顺利，对比计划与实际数据——差距将揭示潜在问题。Step 4: Generate Improvement Actions
步骤4：生成改进行动项
For each improvement area, create an actionable item:
markdown
undefined针对每个待改进点，创建可落地的行动项：
markdown
undefinedImprovement Actions
改进行动项
| ID | Action | Owner | Due Date | Success Criteria | Source |
|---|---|---|---|---|---|
| A-001 | [Specific action] | [Name] | [Date] | [How to verify success] | Improvement #1 |
| A-002 | [Specific action] | [Name] | [Date] | [How to verify success] | Improvement #2 |
| A-003 | [Specific action] | [Name] | [Date] | [How to verify success] | Improvement #3 |
Each action must be:
- Specific (not "improve estimation" but "add estimation review step to grooming")
- Owned (one person accountable)
- Time-bound (due date within next 1-2 sprints)
- Verifiable (success criteria defined)
**Expected:** 2-4 improvement actions with owners and due dates.
**On failure:** If actions are too vague, apply the "how would you verify this was done?" test.| ID | 行动内容 | 负责人 | 截止日期 | 成功标准 | 来源 |
|---|---|---|---|---|---|
| A-001 | [具体行动] | [姓名] | [日期] | [验证成功的方式] | 待改进点#1 |
| A-002 | [具体行动] | [姓名] | [日期] | [验证成功的方式] | 待改进点#2 |
| A-003 | [具体行动] | [姓名] | [日期] | [验证成功的方式] | 待改进点#3 |
每个行动项必须满足：
- 具体明确（不是“改进估算”，而是“在梳理环节增加估算评审步骤”）
- 明确负责人（指定一名责任人）
- 有时间限制（截止日期为未来1-2个冲刺内）
- 可验证（定义成功标准）
**预期结果**：2-4项明确负责人和截止日期的改进行动项。
**失败处理**：若行动项过于模糊，可通过“如何验证该项已完成？”的测试来优化。Step 5: Review Previous Actions and Write Report
步骤5：复查往期行动项并撰写报告
Check previous retrospective actions for closure:
markdown
undefined检查上一次回顾会议行动项的完成情况：
markdown
undefinedPrevious Action Review
往期行动项复查
| ID | Action | Owner | Status | Notes |
|---|---|---|---|---|
| A-prev-001 | [Action from last retro] | [Name] | Closed / Open / Recurring | [Outcome] |
| A-prev-002 | [Action from last retro] | [Name] | Closed / Open / Recurring | [Outcome] |
Flag recurring items (same issue appearing in 3+ retrospectives) — these need escalation or a different approach.
Write the complete retrospective:
```markdown| ID | 行动内容 | 负责人 | 状态 | 备注 |
|---|---|---|---|---|
| A-prev-001 | [上一次回顾的行动项] | [姓名] | 已完成 / 未完成 / 重复出现 | [结果描述] |
| A-prev-002 | [上一次回顾的行动项] | [姓名] | 已完成 / 未完成 / 重复出现 | [结果描述] |
标记重复出现的事项（同一问题在3次及以上回顾中出现）——这类问题需要升级处理或更换解决方式。
撰写完整的回顾报告：
```markdownRetrospective: [Sprint N / Phase Name / Date Range]
回顾会议：[冲刺N / 阶段名称 / 日期范围]
Date: [YYYY-MM-DD]
日期：[YYYY-MM-DD]
Document ID: RETRO-[PROJECT]-[YYYY-MM-DD]
文档ID：RETRO-[项目名称]-[YYYY-MM-DD]
Period Summary
周期总结
- Period: [Sprint N / dates]
- Planned: [N items / N points]
- Completed: [N items / N points]
- Velocity: [N] (previous: [N])
- Unplanned Work: [N items]
- 周期：[冲刺N / 日期范围]
- 计划完成：[N项 / N点数]
- 实际完成：[N项 / N点数]
- 速度：[N]（往期：[N]）
- 非计划工作：[N项]
What Went Well
工作亮点
[From Step 2]
[来自步骤2的内容]
What Needs Improvement
待改进点
[From Step 3]
[来自步骤3的内容]
Improvement Actions
改进行动项
[From Step 4]
[来自步骤4的内容]
Previous Action Review
往期行动项复查
[From Step 5]
Retrospective facilitated by: [Name/Agent]
Save as `RETRO-[YYYY-MM-DD].md`.
**Expected:** Complete retrospective document saved with actions, evidence, and previous action review.
**On failure:** If the retrospective has no improvement actions, it's not driving change — revisit Step 3.[来自步骤5的内容]
回顾会议主持人：[姓名/Agent]
保存为`RETRO-[YYYY-MM-DD].md`。
**预期结果**：生成包含行动项、证据和往期行动项复查内容的完整回顾文档。
**失败处理**：若回顾报告中没有改进行动项，则无法推动变革——需重新回到步骤3。Validation
验证清单
- Retrospective file created with date-stamped filename
- Period summary includes quantitative metrics
- "What Went Well" has 3-5 evidence-backed items
- "What Needs Improvement" has 3-5 evidence-backed items
- Improvement actions have owners, due dates, and success criteria
- Previous retrospective actions reviewed for closure
- Recurring issues flagged
- 已创建带日期戳文件名的回顾文档
- 周期总结包含量化指标
- “工作亮点”部分有3-5项有证据支撑的内容
- “待改进点”部分有3-5项有证据支撑的内容
- 改进行动项明确了负责人、截止日期和成功标准
- 已复查上一次回顾会议的行动项完成情况
- 已标记重复出现的问题
Common Pitfalls
常见误区
- Blame game: Retrospectives review processes and practices, not people. Frame issues as systemic, not personal.
- Actions without follow-through: The biggest retrospective failure. Always review previous actions before creating new ones.
- Too many actions: 2-4 focused actions are better than 10 vague ones. The team can only absorb so many changes.
- No evidence: "We feel estimation is bad" is opinion. "3 of 5 items exceeded estimates by 50%" is data. Always attach evidence.
- Skipping the positives: Only discussing problems is demoralizing. Celebrating wins reinforces good practices.
- 指责他人：回顾会议是复盘流程与实践，而非针对个人。需将问题归因为系统性问题，而非个人问题。
- 行动项无跟进：这是回顾会议最大的失败点。在制定新行动项前，务必复查往期行动项。
- 行动项过多：2-4项聚焦的行动项远胜于10项模糊的行动项。团队能消化的变革是有限的。
- 无证据支撑：“我们觉得估算不准”是主观意见，“5项事项中有3项的实际耗时超出估算50%”才是数据。务必附上证据。
- 忽略正面成果：只讨论问题会打击团队士气。庆祝成果能强化良好实践。
Related Skills
相关技能
- — status reports provide the data for retrospectives
generate-status-report - — improvement actions feed back into the backlog
manage-backlog - — retrospective learnings improve sprint planning accuracy
plan-sprint - — review charter assumptions and risk accuracy
draft-project-charter - — review estimation accuracy against WBS
create-work-breakdown-structure
- —— 状态报告为回顾会议提供数据支持
generate-status-report - —— 改进行动项可反哺产品待办事项管理
manage-backlog - —— 回顾总结的经验可提升冲刺规划的准确性
plan-sprint - —— 可复查项目章程的假设与风险准确性
draft-project-charter - —— 可对比工作分解结构（WBS）验证估算准确性
create-work-breakdown-structure