awesome-claude-code-subagents 之 backlog-grooming：让产品待办事项健康、可估算、随时可进入冲刺的实战指南

• AI 技能/插件
• 人工智能

导读：本文围绕 awesome-claude-code-subagents 仓库中 Business & Product 分类下的 backlog-grooming 子代理定义 展开，系统讲解一个"健康产品待办事项（Healthy Backlog）"应当满足的标准、标准的梳理论（Grooming Session）三段式流程、故事点 / T 恤尺码 / 计划扑克三类估算方法、以及"定义就绪（Definition of Ready）"清单与待办事项分类体系。读完本文，你将掌握如何让 Claude Code 以专职敏捷产品负责人（Agile Product Owner）的身份，帮助团队清理僵尸条目、细化故事、对齐优先级，把待办事项打磨到"可冲刺（sprint-ready）"状态。

一、子代理定位：一个内置的敏捷产品负责人

在 awesome-claude-code-subagents 仓库中，backlog-grooming 是 Business & Product 分类 下的 16 个产品与业务子代理之一。按照 CLAUDE.md 对仓库结构的说明，每个子代理都是一个带 YAML frontmatter 的 Markdown 文件，Claude Code 可以按需加载调用；README.md 将该代理概括为"Agile backlog expert keeping product backlogs healthy——well-estimated, well-defined, prioritized, and sprint-ready. Runs grooming sessions, enforces story readiness, and eliminates zombie tickets"。

它的角色定义非常明确：专家级敏捷产品负责人 + 待办事项精化专员，核心职责是让产品待办事项保持健康——即"估算良好、定义清晰、优先级明确、随时可进入冲刺"，并清楚地区分"加速交付的待办事项"与"拖垮团队的待办事项"之间的差别。

1.1 触发与调用方式

代理 frontmatter 中的description字段同时充当触发规则（Claude Code 据此进行自动选择），其触发场景包括：

• "groom backlog"（梳理待办事项）
• "backlog refinement"（待办事项精化）
• "backlog grooming"（待办事项梳理）
• "clean up backlog"（清理待办事项）
• "refine stories"（精化用户故事）
• "sprint refinement"（冲刺精化）
• "backlog management"（待办事项管理）

1.2 工具权限设计

frontmatter 中的tools字段为Read, Write, Edit, Glob, Grep, WebFetch, WebSearch。对照 README.md 的"Tool Assignment Philosophy"一节，这是一个典型的文档 / 分析型代理配置：既能读取与检索仓库内的故事、工单与既有文档（Read/Glob/Grep），又能借助 WebFetch/WebSearch 获取行业实践与外部参考资料，同时保留 Write/Edit 能力以落地梳理产出物。model字段未单独指定，这意味着它默认跟随主会话所用模型；如需固定成本，可参照 README.md 的 Smart Model Routing 说明为其显式指定model: haiku（快速任务场景）或model: inherit。

二、健康待办事项标准（Healthy Backlog Standards）

原文档给出了判断一个待办事项是否"健康"的六条硬性标准，这是整个梳理工作的验收基线：

1. 顶部 2 个冲刺（Top 2 sprints）：条目必须详细、已估算、随时可进入冲刺；
2. 接下来 2-3 个冲刺（Next 2-3 sprints）：只需粗略估算并带有清晰意图；
3. 更远期的条目（Everything beyond）：只保留方向性描述，不做细节展开；
4. 无僵尸故事（No zombie stories）：超过 90 天没有做出任何决策的条目不得存在；
5. 每条目五要素齐全：必须同时具备负责人（owner）、优先级（priority）、验收标准（acceptance criteria）和完成定义（definition of done）。

这组标准的核心思想是**"按冲刺距离分层管理信息颗粒度"**——越接近排期，故事越要细化；越遥远，只留方向。这与文档中 Part 3 优先级审视、以及后续"Now / Next / Later / Icebox / Won't Do"五类归档体系的逻辑完全同构。

三、梳理论的三段式结构（60-90 分钟，每冲刺一次）

原文档规定，每次 Grooming Session 应控制在60-90 分钟、每个冲刺举行一次，内部严格划分为三个时间盒。

Part 1：待办事项卫生检查（20 分钟）

本环节专门处理"存量垃圾"，具体动作包括：

• 归档或删除超过 90 天仍无行动的故事；
• 标记那些已处于 "ready" 状态却滞留 3 个以上冲刺的条目，追问"为什么还没有被排进开发"；
• 合并重复故事；
• 确认当前优先级反映的是本季度战略，而不是上个季度遗留的方向。

工程视角：这实际上就是一次对 backlog 的"索引重建"。滞留的 ready 条目往往是依赖未暴露、价值已过时或干系人认知漂移的信号，20 分钟时间盒倒逼团队快速分类而非陷入细节讨论。

Part 2：故事精化（40 分钟）

这是整个梳理会的核心重头戏。对每个候选故事（每次会话 5-8 条为上限），按五步流水线逐条过一遍：

1. 朗读故事——把故事大声读出来，确认在场所有人都理解它；
2. 检查验收标准——是否足够具体、可测试（testable）；
3. 列出问题与未知项——开工前我们还需要弄清楚什么；
4. 识别依赖——该故事是阻塞别人，还是被别人阻塞；
5. 估算——采用相对规模（T 恤尺码或故事点）。

Part 3：优先级复核（10-20 分钟）

• 顶部条目是否仍反映当前优先级？
• 本周是否发生了足以重排待办事项顺序的变化？
• 是否有条目需要从 "Next" 提升到 "Now"？

三个部分合计 60-90 分钟、每冲刺一次，形成稳定的节奏。这一会话结构在仓库中并非孤立存在——scrum-master.md 的 "Backlog refinement" 能力清单（story breakdown、acceptance criteria、estimation sessions、grooming cadence 等）与本文档高度互补，后者聚焦"如何把条目打磨到就绪"，前者负责"如何让精化仪式在团队中持续运转"。

四、三类估算方法详解

原文档给出了三种互为补充的相对估算方法，核心原则是相对规模而非时间。

4.1 故事点（Story Points）：斐波那契序列

使用序列1, 2, 3, 5, 8, 13, 21，关键约定：

• 相对规模（Relative sizing），不是绝对工时；
• 1 = 微不足道的小改动；13+ = 太大，必须拆分；
• 21 = epic（史诗），不是故事。

斐波那契序列的非线性递增天然放大了大条目之间的差异，迫使团队在 8/13/21 处停下思考"要不要拆"。拆条行为本身也是故事精化的产出物之一。

4.2 T 恤尺码（T-Shirt Sizing）：XS / S / M / L / XL

• 更快、精度更低；
• 适合**路线图级别（roadmap-level）**的粗粒度估算；
• 当条目进入冲刺排期时，需转换为故事点。

T 恤尺码与故事点的换算关系本仓库未给出固定公式，实践中通常由团队自定义映射（如 XS=1、S=2、M=3、L=5、XL=8），以便在"快速对齐方向"与"精确排期"两种场景间平滑过渡。

4.3 计划扑克（Planning Poker）规则

• 所有人同时投票，防止锚定效应（anchoring）；
• 离群值（outliers）解释理由；
• 讨论后按需重新投票；
• 不要取平均值——必须达成共识。

计划扑克的机制设计（同时投票 + 离群解释 + 重投 + 共识）正是为了规避"首位发言者锚定全场""激进者带偏均值"这两大常见估算陷阱，与 scrum-master 的 "planning poker" 工具项直接呼应。

五、故事就绪清单：Definition of Ready

一个故事要达到"可冲刺（sprint-ready）"状态，须逐项勾选以下六条：

• 验收标准清晰且可测试（Acceptance criteria are clear and testable）
• 涉及 UI 工作时，设计已就绪（Design is available）
• 依赖已识别并解决（Dependencies identified and resolved）
• 已由团队估算（Estimated by the team）
• 能在一个冲刺内完成（Fits within one sprint）
• 测试场景已起草（Test scenarios drafted）

这份 DoR 清单是 Grooming Session Part 2 的实际输出判据：任何未勾满六项的条目，都应该在"梳理产出"中被明确标注为"需要更多工作"而非"可进入冲刺"。

六、待办事项五类归档体系（Backlog Categories）

原文档将 backlog 中的条目按就绪程度与决策状态划分为五类，这也是 Part 1 卫生检查和 Part 3 优先级复核的操作对象：

值得注意的细节是 "Won't Do" 的强制要求——附带理由（with reason noted）。这保证了 backlog 成为团队决策的"可追溯记录"而非信息黑洞，与 Part 1 中"归档而非无限期悬挂"的原则一脉相承。

七、梳理论的交付物（Output Format）

每次会话结束时，backlog-grooming 应交付四类产出：

1. 梳理后的待办事项评估（Groomed backlog assessment）；
2. 可进入冲刺 vs 仍需更多工作的故事清单（Stories ready for sprint vs. needs more work）；
3. 建议归档的条目（Items recommended for archival）；
4. 下次会话的精化议程（Refinement agenda for next session）。

其中"下次会话议程"非常关键：它使每次梳理会首尾相接、形成持续改进闭环，而不是一次性的清理动作。

八、与其他子代理的协作集成

原文档明确给出了四条协作路径，这正是该仓库"多 Agent 编排"设计哲学的体现：

• 与scrum-master协作：负责仪式推进（ceremony facilitation）；
• 与product-manager协作：负责优先级决策；
• 与business-analyst协作：负责故事定义；
• 与project-manager协作：负责时间线对齐。

对照仓库中对应代理的职责边界可以看得更清晰：product-manager.md 负责产品战略、路线图与优先级打分（RICE 等框架），为 backlog-grooming 提供"排什么"的决策输入；scrum-master.md 把 backlog refinement 作为其八大能力域之一，并包含 estimation sessions、ready definition、grooming cadence 等细化动作；business-analyst.md 提供需求挖掘、用户故事创作与验收标准起草能力；project-manager.md 则负责把就绪的条目落进时间线、里程碑与资源计划。业务分类的 README.md 在"Common Business Patterns"中也印证了这一组合——Agile Teams 模式即为 scrum-master（流程）+ product-manager（优先级）+ business-analyst（故事）+ project-manager（追踪）。

九、安装与在 Claude Code 中使用

本文以仓库现状为准说明三种使用方式：

方式一：通过仓库交互式安装脚本（推荐入门）

git clone https://github.com/VoltAgent/awesome-claude-code-subagents.git cd awesome-claude-code-subagents ./install-agents.sh

脚本支持本地 / 远程两种数据源、全局（~/.claude/agents/）与项目级（.claude/agents/）两种安装模式，并可多选安装 categories/08-business-product 下包含 backlog-grooming 在内的任意代理（详见 install-agents.sh）。

方式二：手动拷贝

1. 克隆仓库；
2. 将 backlog-grooming.md 拷贝至~/.claude/agents/（全局可用）或.claude/agents/（当前项目专用）；
3. 按需定制 frontmatter。

方式三：Claude Code 插件市场

claude plugin marketplace add VoltAgent/awesome-claude-code-subagents claude plugin install voltagent-biz

其中voltagent-biz是 Business & Product 分类对应的插件名（见 README.md 的 Categories 章节）。安装完成后，在 Claude Code 中输入groom backlog、backlog refinement或clean up backlog等触发语，或在对话中显式要求"让 backlog-grooming 子代理梳理当前待办事项"，即可让它接管一次完整的梳理会话。

十、实战落地建议

综合原文档与仓库上下文，给出几条可直接落地的实践要点：

1. 把健康标准当作入场检查：在每次梳理会开始前，先用第三节的六条标准给 backlog"体检打分"，把分数写进交付物评估，量化前后对比；
2. 严守 5-8 条的时间盒纪律：Part 2 每会话只精化 5-8 条，宁可高频迭代也不要让梳理会失控变成马拉松；
3. 用 DoR 清单挡回半成品：六个勾选项任何一项缺失，条目就应被标注 "needs more work" 而非强行排入冲刺——这正是"定义就绪"防住"定义完成"未完成条目混入排期的关键；
4. 让估算规则显式化：明确团队的故事点 ↔ T 恤尺码映射、以及 13+ 强制拆分的执行口径，避免估算标准因人而异；
5. 与协作代理串成流水线：优先级拿不准时交给 product-manager，仪式推进交给 scrum-master，故事定义交给 business-analyst，时间线交给 project-manager，让 backlog-grooming 专注做好"打磨就绪"这一件事。

结语

backlog-grooming 子代理的核心价值，在于把"健康待办事项"从一个模糊愿景拆解成可执行的六条标准、三段式会话、三类估算方法与五类归档体系，并以固定的输出格式保证每次梳理会都有可量化、可追溯、可持续的产出。它与仓库中 scrum-master、product-manager、business-analyst、project-manager 等代理协同，构成了完整的产品交付治理链路。对正在使用 Claude Code 管理敏捷团队的读者而言，categories/08-business-product/backlog-grooming.md 这份定义文件本身，就是一份可以直接转化为团队规范的开箱即用的实践模板。

• AI 技能/插件
• 人工智能