![Sprint [] Planning - [Date]](http://pic.xiahunao.cn/yaotu/Sprint [] Planning - [Date])
Sprint [#] Planning - [Date]【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skillsMeeting DetailsDate: [Date]Team: [Team name]Sprint Duration: [Dates]Sprint Goal[Clear statement of what this sprint aims to accomplish]CapacityTeam MemberAvailabilityCapacity (points)[Name][%][#]Total[#]Backlog ReviewHigh Priority Items[From product backlog, linked from task database]Task 1 - [Points]Task 2 - [Points]Sprint BacklogCommitted ItemsTask - [Points] - [Owner]Task - [Points] - [Owner]Total committed: [Points]Stretch GoalsTask - [Points]Dependencies RisksDependencies:[Dependency]Risks:[Risk]Definition of DoneCode complete and reviewedTests written and passingDocumentation updatedDeployed to stagingQA approvedNext StepsTeam begins sprint workDaily standups at [Time]Sprint review on [Date]### Meeting Details先把时空钉死 标题行 # Sprint [#] Planning - [Date] 同时承载了冲刺编号与会议日期例如 # Sprint 25 Planning - 2026-09-14。Meeting Details 一节只需三项会议日期、团队名称、冲刺起止时间。模板刻意保持精简——规划会议不是讨论会元信息一眼可读即可。结合技能评估标准[evaluations/README.md](https://link.gitcode.com/i/227c2dea5a216cfd579f4d132a289e0a)文档标题应包含日期或会议上下文方便日后检索归档。 ### Sprint Goal一句话讲清楚这个冲刺为了什么 模板用 [Clear statement of what this sprint aims to accomplish] 占位要求是**清晰、可验证**的陈述而非任务清单。例如完成用户认证模块改造并上线 API 性能优化。一个可用的判断标准冲刺结束时能明确回答目标达成了没有。 ### Capacity用数据校准承诺 这是规划会议的硬约束环节模板给出了一张三列表格 | 列 | 含义 | 填写建议 | |----|------|----------| | Team Member | 成员姓名 | 逐个列出参与本冲刺的成员 | | Availability | 可用性百分比 | 考虑假期PTO、并行事务后的真实可用度 | | Capacity (points) | 容量故事点 | 成员可承诺的故事点上限 | **Total** 行汇总团队总容量这是后续从待办列表选多少点的量化基准。示例文件 [examples/sprint-planning.md](https://link.gitcode.com/i/722e6826f1be75947c774dc0a096f549) 演示了该节的关键实践团队 5 名工程师、1 人下个冲刺休假80% 容量、结合近 3 个冲刺稳定在 30–35 点的速度velocity最终计算出 Sprint 25 可用约 28 点。**容量计算必须显式扣除休假与并行事务**这是示例中列出的Key Success Factors之一。 ### Backlog Review从产品待办列表锁定候选 High Priority Items 一节的角色是从产品待办事项列表中挑选本冲刺的候选条目。模板特别标注 [From product backlog, linked from task database]强调条目应**来自任务数据库并保持链接**因此使用 mention-page url... 标签内联引用 Notion 页面每个条目后附故事点 markdown - mention-page url...User auth improvements/mention-page - 8 - mention-page url...API performance tuning/mention-page - 5在技能工作流中这一步由Notion:notion-search检索如query: sprint planning product backlog再由Notion:notion-fetch抓取上一冲刺回顾、产品待办列表、当前冲刺进度、团队容量笔记等关键页面详见 examples/sprint-planning.md 第 1、2 步。Sprint Backlog承诺与拉伸分开管理冲刺待办清单被拆成两层Committed Items承诺项[x]/[ ]复选框 mention-page页面引用 故事点 [Owner]负责人。承诺项是冲刺期间必须完成的部分。Stretch Goals拉伸目标仅当承诺项提前完成才追加的备选条目同样带页面引用与故事点不列入承诺总量。**Total committed**: [Points]必须与 Capacity 表格的总容量互相呼应——承诺点应落在团队容量范围内。示例中3 个上个冲刺遗留的技术债任务就是先通过Notion:notion-query-data-sources查询SELECT * FROM tasks WHERE Sprint Sprint 24 AND Status ! Done识别出来、再决定是否纳入承诺或作为拉伸目标的典型场景。Dependencies Risks把隐患摆上台面规划会议上最容易被跳过、却最影响冲刺成败的就是依赖与风险。模板用两组列表强制暴露Dependencies本冲刺依赖的外部条件其他团队交付、第三方服务、审批流程等。Risks可能导致冲刺目标无法达成的风险因素。示例中的典型风险是认证改造需要 QA 时间——这类风险应在规划阶段就标注出来并在能力评估与承诺点数时留出缓冲。Definition of Done让完成有统一标准模板内置了五条默认 DoD 清单Code complete and reviewed代码完成并通过评审Tests written and passing测试编写并通过Documentation updated文档已更新Deployed to staging已部署到预发环境QA approvedQA 验收通过这五条覆盖了编码、测试、文档、部署、验收五个环节杜绝代码写完了就算完成的模糊认知。团队可按需增删但验收标准必须在规划会议上对齐而不是在冲刺中途临时定义。Next Steps让会议产出落到行动模板以三条默认步骤收尾团队开始冲刺工作、每日站会时间、冲刺评审日期。它把规划会议与后续的每日站会、冲刺评审串成闭环确保会议产出不只停留在文档上。实战工作流如何用 Notion MCP 填充并落地该模板模板本身是静态结构真正的价值在于notion-meeting-intelligence技能围绕它构建的端到端流程。示例 examples/sprint-planning.md 展示了一次完整的明天冲刺规划会议准备1. 搜索上下文Notion:notion-search以sprint planning product backlog为查询词限定 engineering-team teamspace定位上一冲刺回顾、产品待办列表、当前冲刺进度、团队容量笔记。2. 抓取细节Notion:notion-fetch拉取 4 个关键页面沉淀关键上下文——上一冲刺完成 32/35 点91%、连续 3 个冲刺速度稳定在 30–35 点、团队 5 人1 人休假、80% 容量、顶部待办条目用户认证改进、API 性能、移动端响应式修复。3. 查询当前冲刺任务Notion:notion-query-data-sources执行结构化查询发现 3 个技术债遗留任务需要评估是否带入下个冲刺。4. 创建内部预读Internal Pre-ReadNotion:notion-create-pages生成Sprint 25 Planning - Pre-Read (Internal)包含 Sprint 24 总结速度、遗留、Sprint 25 团队容量、带故事点的顶部候选条目、技术依赖、风险项。5. 创建会议议程Agenda再次调用Notion:notion-create-pages生成对外议程按时间盒组织——回顾 Sprint 24 完成情况5 分钟、讨论遗留项5 分钟、评审容量28 点可用、挑选待办条目30 分钟、识别依赖与风险10 分钟、确认承诺10 分钟。6. 链接文档将预读、议程、上一回顾、待办列表互相交叉链接。技能评估evaluations/README.md强调这一流程的关键成功标准是产出两份文档——内部预读含团队上下文、容量、阻碍项标注 INTERNAL ONLY与外部议程只含会议结构与讨论主题用mention-page标签引用至少 2–3 个 Notion 页面作为来源议程每个环节带时间分配。而 SKILL.md 中的工作流进一步要求先搜索再抓取先 Notion 事实后 Codex 研究、区分 Notion 事实与 Codex 洞察、为每个议程项分配负责人与时间盒、计划变更时用Notion:notion-update-page更新页面。前置条件连接 Notion MCP要运行上述工作流需要 Codex 环境接入 Notion MCP 服务。技能依赖定义在 agents/openai.yaml 中Notion MCP server传输方式为 streamable_http地址https://mcp.notion.com/mcp。配置步骤源自 SKILL.md# 1. 添加 Notion MCP codex mcp add notion --url https://mcp.notion.com/mcp # 2. 启用远程 MCP 客户端二选一 # 在 config.toml 中设置 [features].rmcp_client true codex --enable rmcp_client # 3. 使用 OAuth 登录 codex mcp login notion【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Sprint [#] Planning - [Date]【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skillsMeeting DetailsDate: [Date]Team: [Team name]Sprint Duration: [Dates]Sprint Goal[Clear statement of what this sprint aims to accomplish]CapacityTeam MemberAvailabilityCapacity (points)[Name][%][#]Total[#]Backlog ReviewHigh Priority Items[From product backlog, linked from task database]Task 1 - [Points]Task 2 - [Points]Sprint BacklogCommitted ItemsTask - [Points] - [Owner]Task - [Points] - [Owner]Total committed: [Points]Stretch GoalsTask - [Points]Dependencies RisksDependencies:[Dependency]Risks:[Risk]Definition of DoneCode complete and reviewedTests written and passingDocumentation updatedDeployed to stagingQA approvedNext StepsTeam begins sprint workDaily standups at [Time]Sprint review on [Date]### Meeting Details先把时空钉死 标题行 # Sprint [#] Planning - [Date] 同时承载了冲刺编号与会议日期例如 # Sprint 25 Planning - 2026-09-14。Meeting Details 一节只需三项会议日期、团队名称、冲刺起止时间。模板刻意保持精简——规划会议不是讨论会元信息一眼可读即可。结合技能评估标准[evaluations/README.md](https://link.gitcode.com/i/227c2dea5a216cfd579f4d132a289e0a)文档标题应包含日期或会议上下文方便日后检索归档。 ### Sprint Goal一句话讲清楚这个冲刺为了什么 模板用 [Clear statement of what this sprint aims to accomplish] 占位要求是**清晰、可验证**的陈述而非任务清单。例如完成用户认证模块改造并上线 API 性能优化。一个可用的判断标准冲刺结束时能明确回答目标达成了没有。 ### Capacity用数据校准承诺 这是规划会议的硬约束环节模板给出了一张三列表格 | 列 | 含义 | 填写建议 | |----|------|----------| | Team Member | 成员姓名 | 逐个列出参与本冲刺的成员 | | Availability | 可用性百分比 | 考虑假期PTO、并行事务后的真实可用度 | | Capacity (points) | 容量故事点 | 成员可承诺的故事点上限 | **Total** 行汇总团队总容量这是后续从待办列表选多少点的量化基准。示例文件 [examples/sprint-planning.md](https://link.gitcode.com/i/722e6826f1be75947c774dc0a096f549) 演示了该节的关键实践团队 5 名工程师、1 人下个冲刺休假80% 容量、结合近 3 个冲刺稳定在 30–35 点的速度velocity最终计算出 Sprint 25 可用约 28 点。**容量计算必须显式扣除休假与并行事务**这是示例中列出的Key Success Factors之一。 ### Backlog Review从产品待办列表锁定候选 High Priority Items 一节的角色是从产品待办事项列表中挑选本冲刺的候选条目。模板特别标注 [From product backlog, linked from task database]强调条目应**来自任务数据库并保持链接**因此使用 mention-page url... 标签内联引用 Notion 页面每个条目后附故事点 markdown - mention-page url...User auth improvements/mention-page - 8 - mention-page url...API performance tuning/mention-page - 5在技能工作流中这一步由Notion:notion-search检索如query: sprint planning product backlog再由Notion:notion-fetch抓取上一冲刺回顾、产品待办列表、当前冲刺进度、团队容量笔记等关键页面详见 examples/sprint-planning.md 第 1、2 步。Sprint Backlog承诺与拉伸分开管理冲刺待办清单被拆成两层Committed Items承诺项[x]/[ ]复选框 mention-page页面引用 故事点 [Owner]负责人。承诺项是冲刺期间必须完成的部分。Stretch Goals拉伸目标仅当承诺项提前完成才追加的备选条目同样带页面引用与故事点不列入承诺总量。**Total committed**: [Points]必须与 Capacity 表格的总容量互相呼应——承诺点应落在团队容量范围内。示例中3 个上个冲刺遗留的技术债任务就是先通过Notion:notion-query-data-sources查询SELECT * FROM tasks WHERE Sprint Sprint 24 AND Status ! Done识别出来、再决定是否纳入承诺或作为拉伸目标的典型场景。Dependencies Risks把隐患摆上台面规划会议上最容易被跳过、却最影响冲刺成败的就是依赖与风险。模板用两组列表强制暴露Dependencies本冲刺依赖的外部条件其他团队交付、第三方服务、审批流程等。Risks可能导致冲刺目标无法达成的风险因素。示例中的典型风险是认证改造需要 QA 时间——这类风险应在规划阶段就标注出来并在能力评估与承诺点数时留出缓冲。Definition of Done让完成有统一标准模板内置了五条默认 DoD 清单Code complete and reviewed代码完成并通过评审Tests written and passing测试编写并通过Documentation updated文档已更新Deployed to staging已部署到预发环境QA approvedQA 验收通过这五条覆盖了编码、测试、文档、部署、验收五个环节杜绝代码写完了就算完成的模糊认知。团队可按需增删但验收标准必须在规划会议上对齐而不是在冲刺中途临时定义。Next Steps让会议产出落到行动模板以三条默认步骤收尾团队开始冲刺工作、每日站会时间、冲刺评审日期。它把规划会议与后续的每日站会、冲刺评审串成闭环确保会议产出不只停留在文档上。实战工作流如何用 Notion MCP 填充并落地该模板模板本身是静态结构真正的价值在于notion-meeting-intelligence技能围绕它构建的端到端流程。示例 examples/sprint-planning.md 展示了一次完整的明天冲刺规划会议准备1. 搜索上下文Notion:notion-search以sprint planning product backlog为查询词限定 engineering-team teamspace定位上一冲刺回顾、产品待办列表、当前冲刺进度、团队容量笔记。2. 抓取细节Notion:notion-fetch拉取 4 个关键页面沉淀关键上下文——上一冲刺完成 32/35 点91%、连续 3 个冲刺速度稳定在 30–35 点、团队 5 人1 人休假、80% 容量、顶部待办条目用户认证改进、API 性能、移动端响应式修复。3. 查询当前冲刺任务Notion:notion-query-data-sources执行结构化查询发现 3 个技术债遗留任务需要评估是否带入下个冲刺。4. 创建内部预读Internal Pre-ReadNotion:notion-create-pages生成Sprint 25 Planning - Pre-Read (Internal)包含 Sprint 24 总结速度、遗留、Sprint 25 团队容量、带故事点的顶部候选条目、技术依赖、风险项。5. 创建会议议程Agenda再次调用Notion:notion-create-pages生成对外议程按时间盒组织——回顾 Sprint 24 完成情况5 分钟、讨论遗留项5 分钟、评审容量28 点可用、挑选待办条目30 分钟、识别依赖与风险10 分钟、确认承诺10 分钟。6. 链接文档将预读、议程、上一回顾、待办列表互相交叉链接。技能评估evaluations/README.md强调这一流程的关键成功标准是产出两份文档——内部预读含团队上下文、容量、阻碍项标注 INTERNAL ONLY与外部议程只含会议结构与讨论主题用mention-page标签引用至少 2–3 个 Notion 页面作为来源议程每个环节带时间分配。而 SKILL.md 中的工作流进一步要求先搜索再抓取先 Notion 事实后 Codex 研究、区分 Notion 事实与 Codex 洞察、为每个议程项分配负责人与时间盒、计划变更时用Notion:notion-update-page更新页面。前置条件连接 Notion MCP要运行上述工作流需要 Codex 环境接入 Notion MCP 服务。技能依赖定义在 agents/openai.yaml 中Notion MCP server传输方式为 streamable_http地址https://mcp.notion.com/mcp。配置步骤源自 SKILL.md# 1. 添加 Notion MCP codex mcp add notion --url https://mcp.notion.com/mcp # 2. 启用远程 MCP 客户端二选一 # 在 config.toml 中设置 [features].rmcp_client true codex --enable rmcp_client # 3. 使用 OAuth 登录 codex mcp login notion【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
