简介：围绕“基于JIRA的敏捷开发项目管理”这一主题，面向产品负责人、Scrum Master及研发测试成员，梳理Scrum角色分工、迭代流程与JIRA工具配置的对应关系，适合初、中级团队导入敏捷管理时参考。压缩包共1个docx文件，大小约6.55MB，内容集中，便于按章节查阅和团队内部分享，目前已有3424人学习。文档覆盖product owner、scrum master与scrum team的职责边界，并展开头脑风暴、需求筛选、工作量估算、Sprint拆分和评估复盘五个环节，同时说明时间燃尽图、每日站会、bugs sprint等实践。还结合项目计划表、JIRA用户准备、Scrum项目与Boards搭建，呈现从任务拆分到进度跟踪的落地思路，帮助读者理解如何借助JIRA提升敏捷项目的协作与交付效率。
1. 白板上的 Scrum 搬进 JIRA，第一个 Sprint 最容易翻车的地方
「JIRA 敏捷」这套组合在小团队里几乎成了默认选项，但我见过太多团队第一个 Sprint 就翻车：白板上 to do / in progress / done 三列跑得挺顺，一进 JIRA 就变成一堆没有估时、没有子任务的 Story，燃尽图从第一天就是一条平线。问题不在工具，在于白板时代那套「口头拆分 + 口头估时」没有落成字段和状态机。这份资料把 Scrum 的五个步骤——头脑风暴、需求减法与 PRD、工作量估算、Sprint 循环、评估——和 JIRA 的建项目、建 Board、版本周期设置串成了一条线。它适合 10 人以内、正准备从白板迁移到系统化管理的开发测试团队，也适合 Scrum Master 拿去对照自查：你手上的 Sprint，到底是真在迭代，还是只是把任务换了个地方存。
2. 角色与工作项建模：把三个角色落成 JIRA 权限和三层任务
2.1 Product Owner、Scrum Master、Scrum Team 在 JIRA 里的权限边界
原文对三个角色的定义很干脆：Product Owner 是能对功能流程、业务流程拍板的人，Scrum Master 是解决团队各类问题、领导项目的人，Scrum Team 是具体开发和测试的人。这三句话在白板上靠人盯，在 JIRA 里必须翻译成权限，否则「拍板」和「改需求」会混成一件事。
我一般的分法是：Scrum Master 给项目的 Administrators，因为他要管 Board 配置、Sprint 启停、字段方案和版本设置，这些动作开发人员不需要；开发和测试给 Developers，能改状态、能填估时、能拆子任务、能被分配 issue，但不能动 Sprint 范围和 Board 配置；Product Owner 给 Users 或者单独建一个「需求评审」组，能建 Story、能排优先级、能在验收时改状态，但不给「管理 Sprint」的权限。
最后这条边界最容易被妥协。很多团队觉得 PO 是需求方，给管理员省事，结果就是 Sprint 进行到第三天，PO 直接往当前 Sprint 里塞了五个 Story，燃尽图当场往上翘。这不是 PO 的问题，是权限设计把「变更」变成了零成本动作。需求变更本身没错，错的是它没有留下痕迹。
| 角色 | JIRA 项目角色 | 该给的能力 | 不该给的能力 |
|---|---|---|---|
| Product Owner | Users / 需求评审组 | 建 Story、排优先级、验收改状态 | 改 Sprint 范围、改 Board 配置 |
| Scrum Master | Administrators | 管 Board、启停 Sprint、管字段与版本 | 代替 PO 对需求拍板 |
| Scrum Team | Developers | 改状态、填估时、拆子任务 | 管理 Sprint、修改版本 |
还有一层是「拍板」怎么在系统里体现。我的做法是给 Story 加一个简单的选择字段，值只有「待确认 / 已确认 / 变更中」，PO 确认后才允许拉进 Sprint。这个字段不复杂，但它把口头承诺变成了可查的记录，周会上不用再翻聊天记录对质。
2.2 先建用户和组，再建项目：顺序反了就是一堆空的下拉框
原文的准备工作第二条写得很明确：团队中所有成员必须已经在 JIRA 中建立用户，并可以正常登陆。这个顺序不能反。JIRA 的项目角色绑定的是用户或组，人没建、组没进，后面分配 issue 时 Assignee 下拉框就是空的，很多人第一反应是「权限出 bug 了」，其实是用户根本没进这个项目角色。
常见做法是三层：全局建用户 → 建组（比如 dev-team、qa-team、po-group）→ 项目角色绑组，而不是逐个用户绑。人员流动时只改组成员，不动项目配置，这是运维习惯，能省掉大量重复劳动。下面这段是 Cloud 版的建用户和入组调用，Server 版的路径和字段名略有差异，按自己实例的 API 文档调。
# 建用户：emailAddress 必须是唯一登录名，products 决定能访问哪些应用 curl -s -u "$JIRA_USER:$JIRA_TOKEN" \ -X POST "$JIRA_BASE/rest/api/3/user" \ -H "Content-Type: application/json" \ -d '{"emailAddress":"dev1@example.com","displayName":"dev1","products":["jira-software"]}' # 把用户加入开发组：groupId 或 groupname 二选一，按实例返回的字段来 curl -s -u "$JIRA_USER:$JIRA_TOKEN" \ -X POST "$JIRA_BASE/rest/api/3/group/user?groupname=dev-team" \ -H "Content-Type: application/json" \ -d '{"accountId":"<上一步返回的 accountId>"}'参数说明：JIRA_USER用管理员账号，JIRA_TOKEN用 API token 而不是登录密码，JIRA_BASE是实例地址且末尾不要带斜杠。products字段决定这个账号有没有 JIRA Software 的许可，漏了这一步，用户能登录但进不了 Board，现象很像权限故障。
执行完别急着往下走，先做一次验证：用新账号登录，打开目标项目，看能不能被分配 issue、能不能看到 Board。这一步花两分钟，比后面排查半小时划算。
2.3 Epic、Story、Sub-task 三层拆分与那条 16 小时线
原文给了一条很硬的标准：最小任务量的工作小时不能超过 16 小时。这条线在 JIRA 里就是拆分的触发器，不是建议值。我一般这样映射三层工作项：Epic 对应一个功能域或者一个 Sprint 目标下的大块；Story 对应可独立验收的功能点；Sub-task 对应 16 小时以内的工作包，原型、logo、UI、前端、接口、测试各成一条。
这里有个 JIRA 的硬约束要提前知道：Sub-task 不能跨 Sprint，也不能单独拖进 Backlog 排序，它永远挂在父 Story 下面。所以拆分要拆在 Story 内部，而不是把一堆零散任务直接建成 Story 再指望 Board 帮你归类。父 Story 的估时可以是子任务之和，也可以留空，但子任务必须逐条填 Original Estimate，否则燃尽图算不出来。
| Issue Type | Summary | Original Estimate | 说明 |
|---|---|---|---|
| Story | 登录模块 | 空 | 父级，按功能验收 |
| Sub-task | 登录页原型 | 8h | 未超过 16h |
| Sub-task | 登录页 UI 设计 | 6h | 未超过 16h |
| Sub-task | 登录接口开发 | 12h | 未超过 16h |
| Sub-task | 登录前端联调 | 14h | 未超过 16h |
| Sub-task | 登录用例与回归 | 8h | 未超过 16h |
拆分完成后跑一遍校验，比人眼扫表格可靠。这段脚本读计划 CSV，把所有超过 16 小时的行打出来，导入前先修一遍。
import csv LIMIT = 16 # 单个最小任务的小时上限，来自 Scrum 的工作量估算标准 with open("plan.csv", encoding="utf-8") as f: for row in csv.DictReader(f): raw = (row.get("estimate_hours") or "").strip() if not raw: print(f"[缺估时] {row['summary']}") continue hours = float(raw) if hours > LIMIT: print(f"[需拆分] {row['summary']} 估时 {hours}h，超出 {hours - LIMIT}h")逻辑很直白：先判空再比大小，空估时和超估时是两类问题，分开报。参数只有LIMIT一个，团队如果约定 12 小时或者 2 天，改这个常量就行，但改完要同步到 Board 的统计口径，否则脚本按 16 小时校验、燃尽图按别的口径算，两边对不上。
2.4 项目计划表怎么变成 JIRA 字段：映射定死再导入
原文第三步会输出一张项目计划表，JIRA 的 Scrum 管理就是基于这张表。我的习惯是先把列定死再谈导入，列不定死，后面每加一个字段就要重导一次。常用映射如下：
| 计划表列 | JIRA 字段 | 填写要点 |
|---|---|---|
| 模块 | Component | 一个 issue 只挂一个主模块，别当标签用 |
| 标题 | Summary | 动词开头，写完能判断是否可验收 |
| 估时 | Original Estimate | 表格里写小时，REST 接口传秒 |
| 优先级 | Priority | 只留三档，多了等于没有 |
| 负责人 | Assignee | 必须是已进项目角色的用户 |
| 目标版本 | Fix Version | 和 Sprint 不是一回事，后面单独讲 |
| 验收标准 | Description | 至少写一条可执行的判断条件 |
这里有个非常容易翻车的参数：JIRA 的 Original Estimate 字段内部按秒存储。CSV 导入时写8h通常能被解析，但走 REST API 时必须传28800，传 8 会被当成 8 秒，燃尽图直接失真到没法看。我见过有人排查了一下午「为什么估时显示 0m」，最后发现是单位问题，这种坑属于看一遍就能避开、没看就必然踩的类型。
3. Board 与 Sprint 搭建：从项目容器到版本开发周期的顺序
3.1 先有项目再有 Board，Board 的本质是一条 JQL
原文写「建立一个 Scrum 的 Boards，同时也建好了项目」，这是 JIRA 的便利之处：用 Scrum 模板建项目时会自动带一个 Board。但顺序要理解清楚，Board 只是一个视图，它靠 filter 圈定 issue 范围，项目才是容器。不理解这层关系，后面就会遇到「新建的 Task 在 Board 上不显示」这类问题。
常见做法是建完项目先去看一眼 Board 的 filter。默认 filter 往往限定了 issue 类型，只包含 Story、Bug、Task 中的某几种，如果团队习惯用「技术任务」这种自定义类型，它就不会出现在 Board 上。改法有两种：改 filter 把类型加进去，或者统一团队的工作项类型，后者更根本。
建项目的步骤大致是：选 Scrum 模板 → 填项目名称和 key → 确认 Board 生成 → 检查列配置 → 检查估时统计字段。key 一旦定下不建议改，它会出现在所有 issue 编号和 JQL 里，改一次等于全量重写查询。
建完之后做一次冒烟验证：手动建一条 Story，填 8h 估时，看它是否出现在 Board 的 To Do 列，看 Sprint 下拉框能不能选中。三步都通过，再往里面批量导入。
3.2 三列不够用：列与状态的映射要一次定对
白板只有三列是物理限制，JIRA 里没必要照抄。我一般用五个状态：To Do、In Progress、In Review、Done，再加上用 Flag 标记的阻塞，或者单独一个 Blocked 状态。列配置的关键不是列名好看，而是每一列的进入和退出条件明确。
| 列 | 包含状态 | 进入条件 | 退出条件 |
|---|---|---|---|
| 待办 | To Do | 已估时、已排进 Sprint | 有人开始动手 |
| 进行中 | In Progress | 已分配负责人 | 代码提交并自测通过 |
| 评审中 | In Review | 有可评审的产出 | 评审通过或打回 |
| 完成 | Done | 验收标准逐条满足 | Sprint 结束后不再变动 |
状态流转靠 workflow 的 condition 和 validator 卡住。比如「没有填写测试结论不能进 Done」「没有关联版本不能进评审」，这类规则写在 workflow 里比写在制度文档里有效得多，因为制度会被绕过，validator 不会。代价是配置麻烦，但一次配好能管很久。
还要注意 Board 的列映射是「状态 → 列」，一个列可以包含多个状态，但一个状态只能落在一列。有人把 Done 和 In Review 放同一列，结果累积流图看不出评审堆积，等于自己把瓶颈藏起来了。
3.3 Sprint 切分：按重要度排，按上一轮的实际完成量定容量
原文的顺序是：先做主要功能，再到次要功能，再到小功能，最后的 Sprint 一般修 bug。这个顺序没问题，但落地要补两个约束，否则 Sprint 会变成「这个月要干完的事」的别名。
第一个约束是每个 Sprint 必须有独立可验收的目标。不是「完成登录和支付」，而是「用户能用手机号登录并完成一笔测试支付」。目标写得出来，Sprint 评审才有东西可看。第二个约束是容量按上一 Sprint 的实际完成量定，不按「大家都很努力」定。头两个 Sprint 没有历史数据，宁可保守，按总估时的六成排，跑完两轮再调。
| Sprint | 目标 | 内容范围 | 容量参考 |
|---|---|---|---|
| Sprint 1 | 核心链路可走通 | 主要功能的原型、UI、主流程开发 | 上一轮完成量的 100% |
| Sprint 2 | 主流程闭环 | 次要功能、接口联调 | 同上，允许 ±10% |
| Sprint 3 | 边缘场景补齐 | 小功能、异常分支 | 同上 |
| Sprint 4 | 可交付 | 集中修 bug、回归 | 预留 30% 给缺陷 |
Sprint 的起止日期要填，不填的话燃尽图的理想线画不出来。长度上 10 人以内团队用两周比较稳，一周太短、光开会就占掉不少时间，四周太长、范围变化压不住。
3.4 版本开发周期设置：Fix Version 不是 Sprint
原文提到「版本开发周期设置」，这一步经常被跳过，然后所有人把版本和 Sprint 当同义词用。两者关系是多对多：一个版本可以跨多个 Sprint 交付，一个 Sprint 也可能只覆盖版本的一部分。版本回答「什么时候交付什么」，Sprint 回答「这两周做什么」。
建版本的要点是填开始日期和发布日期，然后把 issue 关联到版本。版本发布（release）时，未完成的 issue 会被移到哪个版本、要不要移，这一步必须人工确认。默认行为不一定符合预期，直接点发布很容易出现「版本发了但功能没上」的黑匣子，事后只能靠翻历史记录还原。
# 建 Sprint：originBoardId 必填，日期用 ISO 8601 带时区 curl -s -u "$JIRA_USER:$JIRA_TOKEN" \ -X POST "$JIRA_BASE/rest/agile/1.0/sprint" \ -H "Content-Type: application/json" \ -d "{\"name\":\"Sprint 1\",\"startDate\":\"${START}\",\"endDate\":\"${END}\",\"originBoardId\":${BOARD_ID}}" # 建版本：project 用项目 key，releaseDate 决定版本报告的时间轴 curl -s -u "$JIRA_USER:$JIRA_TOKEN" \ -X POST "$JIRA_BASE/rest/api/3/version" \ -H "Content-Type: application/json" \ -d "{\"name\":\"v1.0\",\"project\":\"AGILE-DEMO\",\"startDate\":\"${START_DATE}\",\"releaseDate\":\"${RELEASE_DATE}\"}"参数说明：START、END用2025-01-06T09:00:00.000+08:00这种带时区的格式，只写日期部分时区会按服务器默认走，跨时区团队会对不上；BOARD_ID是数字，从 Board 地址栏里取；project用 key 不用项目名。两个接口都要求调用者有对应权限，Scrum Master 账号能跑通，普通开发账号会返回 403，这是权限设计生效的表现，不是接口坏了。
4. 燃尽图与站会：把每天 10 分钟变成可追溯的数据
4.1 燃尽图的三条线，以及每天必须更新的那个字段
JIRA 的 Sprint 燃尽图上有三条线：理想线从 Sprint 第一天的总估时一路降到零；剩余工作线按每天的实际剩余估时绘制；范围变化线记录 Sprint 期间估时的增减。原文说「不管任务是否按时完成都必须记录」，翻译成 JIRA 的操作就是每天更新 Remaining Estimate，而不是只在任务完成时把状态改成 Done。
这里有个模式选择：Remaining Estimate 可以设成「完成时自动清零」，也可以设成「手动填写剩余」。前者省事但失真，一个 16 小时的任务做了 12 小时，图上还显示 16，最后一天突然掉到 0，曲线像悬崖。后者每天多花十秒，但曲线是真实的。我一般建议 Scrum 团队用手动模式，尤其是新团队，前两个 Sprint 的曲线形状比数字本身更有参考价值。
燃尽图的统计字段也要对齐。Board 设置里 Estimation Statistic 可以选 Story Points 或 Original Estimate，选哪个，图上算的就是哪个。团队按小时估时就选后者，别一边按小时填、一边用故事点画图，两条数据永远对不上。
4.2 站会三问对应 JIRA 上的三个动作
原文的三问很经典：今天做了什么、明天打算做什么、遇到什么困难。落到 JIRA 上，这三问其实对应三个动作，而且动作要发生在会前，不是会上。
| 站会三问 | JIRA 动作 | 谁来做 | 时机 |
|---|---|---|---|
| 今天做了什么 | 完成项状态流转，剩余估时清零 | 任务负责人 | 会前 5 分钟 |
| 明天打算做什么 | 从 To Do 拉到 In Progress，确认负责人 | 任务负责人 | 会前 5 分钟 |
| 遇到什么困难 | 打 Flag 标记，或在评论里写明阻塞原因 | 任务负责人 | 会上口述，会后补录 |
站会本身控制在 10 分钟左右。做法是站着开、按 Board 从左到右过、只讲三问、不在会上解决技术问题。遇到的困难记下来，Scrum Master 会后单独跟进，这是他的核心职责，原文写得很清楚：解决开发团队的困难，让项目快速进展下去。
会上不要现场改 JIRA，一改就会有人开始讨论字段怎么填，十分钟变半小时。会前更新、会上只对齐，这个习惯坚持两个 Sprint 就能固定下来。
4.3 周会看燃尽，月会看版本：视图选错了会白开
周会由 Scrum Master 主持，Product Owner 最好在场，看三样东西：当前 Sprint 的燃尽图、未完成项清单、被 Flag 的阻塞项。周会要出的决策只有一个：剩下这几天，范围要不要调。调就明说，记进范围线；不调就接受，别在会上反复讨论。
月会由 Product Owner 主导，看的是版本层面的东西：版本报告能预测按当前速度什么时候能发；累积流图能看出哪个列在堆积，堆积的地方就是瓶颈；控制图能看单个任务的周期时间分布，尾部特别长的那些就是反复返工的类型。
| 会议 | 频率 | 主要视图 | 要出的决策 |
|---|---|---|---|
| 站会 | 每天 | Board 当前列 | 今天谁做什么、谁被卡住 |
| 周会 | 每周 | Sprint 燃尽图、未完成清单 | 范围是否调整 |
| 月会 | 每月 | 版本报告、累积流图 | 版本是否延期、瓶颈在哪 |
| 评审 | 每 Sprint | 已完成项与验收标准 | 是否接受本 Sprint 产出 |
原文说月会上 Product Owner 要指出产品开发是否在期待范围内，这句话的重量在于：如果月会只看完成率百分比，PO 是判断不出来的，必须看版本报告的时间预测和累积流图的趋势。
4.4 燃尽图不动时的排查顺序
最常被问的一个问题是「燃尽图怎么是一条平线」。按下面这个顺序查，基本三轮内能定位，别一上来就怀疑工具。
| 顺序 | 检查项 | 判断依据 |
|---|---|---|
| 1 | Sprint 是否已开始 | Sprint 状态是 Future 时不出图 |
| 2 | issue 是否有估时 | Original Estimate 为空的不计入 |
| 3 | Board 统计字段 | 选的是故事点还是原始估时 |
| 4 | Board filter 范围 | 当前 issue 类型是否被 filter 排除 |
| 5 | 剩余估时是否有人更新 | 全自动清零模式下曲线会失真 |
第 2 项和第 5 项占了我遇到的绝大多数情况。前者是导入时漏了估时，后者是团队没人改剩余时间。两个都不是配置问题，是流程问题，改配置解决不了。
5. 避坑与排查：五条从平线燃尽图到失控 Sprint 的血泪记录
5.1 估时与燃尽图相关的问题
现象：Sprint 开始第三天，燃尽图还是一条贴着零的直线，团队明明每天都在提交代码。
原因：Story 只填了 Story Points，没填 Original Estimate，而 Board 的统计字段选的是 Original Estimate。两边口径不一致，图上自然什么都没算进去。另一种情况是估时从 CSV 导入时单位传错，8 小时变成 8 秒，图上看起来工作量约等于零。
解决：先统一口径，团队按小时管理就把统计字段设成 Original Estimate，按点数管理就全部改用 Story Points，不要混。然后跑一次 JQL 把所有估时为空且未完成的 issue 拉出来补齐，导入脚本里加单位校验，REST 传秒、界面填小时、CSV 写8h，三处对齐之后再导。
现象：Sprint 进行到一半，燃尽图突然往上翘，Product Owner 在会上问是不是进度造假。
原因：中途往当前 Sprint 加了新 Story，而且带了估时。范围线确实记录了这次变化，但没有人提前说过，图上看起来就是「活越干越多」。这种情况在权限给得太宽的团队里特别常见。
解决：加需求走变更流程，要么换出等量任务保持总量不变，要么明确记入范围线并在周会上说明原因。关键不是禁止变更，是让变更可见。同时把「管理 Sprint」的权限从开发组收走，只留 Scrum Master。
5.2 Sprint 节奏与流程相关的问题
现象：连续几个 Sprint 的完成量忽高忽低，规划时完全没法参考，团队自己也不信这个数字。
原因：上一个 Sprint 结束时没有点 Complete Sprint，未完成的 issue 一直挂在原 Sprint 里，或者被直接拖进下一个 Sprint 但没有重新估剩余时间。两种做法都会让速度统计把「没做完的」和「做完了的」混在一起算。
解决：每个 Sprint 到期必须关闭，未完成项选择移到 Backlog 或下一个 Sprint，移之前重新估剩余工时。这条执行两轮之后，速度数据才有参考价值。关闭 Sprint 时那句「未完成项去哪」的确认不要一路回车，逐个看一眼。
现象：站会开 25 分钟，一半时间在对 JIRA 字段，另一半在讨论技术方案。
原因：会前没人更新 Board，所有人到会上才开始回忆昨天干了什么；Scrum Master 习惯在会上直接解决问题，一讨论就收不住。时间一长，站会变成汇报会，大家开始抵触。
解决：会前 5 分钟各自更新状态和剩余估时；会上只回答三问，遇到需要讨论的问题记在便签上，会后拉相关的人单聊；用一个看得见的计时器，超过 12 分钟就截断。前一周会很别扭，第二周就顺了。
5.3 权限与流程约束相关的问题
现象：一条 Story 从 To Do 直接跳到 Done，中间没有评审记录；问起来说「昨天就测过了」。
原因：Developers 组被给了过宽的权限，workflow 里也没有任何 condition 拦住状态跳转。工具层面允许一步到位，流程层面就一定会有人图省事。
解决：收权限，同时给 workflow 加 condition，比如「没有测试结论字段不能进 Done」「没有关联版本不能进评审」。规则写在工具里比写在制度文档里有效，因为绕过工具需要额外操作，绕过文档只需要忘性。
现象：Sprint 结束做评审，PO 说这不是我要的，团队说需求文档上就是这么写的，双方各执一词。
原因：Story 的描述里只有一句功能名，没有可执行的验收标准；PO 在开发过程中也没有参与过中间确认，只在最后出现。
解决：每条 Story 的 Description 至少写一条能判断真假的验收条件，比如「输入错误验证码三次后锁定十分钟」。周会请 PO 到场，看的是当前 Sprint 的完成项而不是文档。评审时对着验收标准逐条过，不过就是不过，进下一个 Sprint 修。
6. JQL 与关闭核对：把 Scrum 数据变成能复查的证据
前面所有配置最终都要落到「能查出来」。JQL 是 JIRA 里最值得花半小时学的东西，下面几条是我每个项目都会存的过滤器，直接改项目 key 就能用。
-- 当前 Sprint 未完成，周会前必看 project = "AGILE-DEMO" AND sprint in openSprints() AND status != Done -- 估时为空且未完成，燃尽图平线的头号嫌疑 project = "AGILE-DEMO" AND originalEstimate is EMPTY AND status != Done -- 估时超过 16 小时，该拆没拆的 project = "AGILE-DEMO" AND originalEstimate > 16h AND status != Done -- 被标记阻塞的，站会后 Scrum Master 跟进 project = "AGILE-DEMO" AND flagged is not EMPTY -- 跨 Sprint 遗留，速度失真的来源 project = "AGILE-DEMO" AND sprint in closedSprints() AND status != Done参数说明：project换成自己的项目 key，带连字符要加引号；16h里的h是 JQL 的时间单位，也可以写2d；flagged在部分实例里显示名不同，以字段实际 ID 为准。这几条查询可以存成过滤器挂到仪表盘上，周会直接投屏，不用现场敲。
真正让数据可信的不是查询，是关闭 Sprint 前的核对动作。我现在固定走五步：先跑「估时为空」确认没有漏估；再跑「当前 Sprint 未完成」逐条决定去留；然后检查每条未完成项是否重估了剩余时间；接着确认版本关联没有漏；最后才点 Complete Sprint。五步加起来不到十分钟，但能避免后面花两小时解释为什么速度曲线像心电图。
这个习惯是被坑出来的。早些年我图快，Sprint 到点直接关闭，未完成项一股脑拖进下一个 Sprint，估时原样带过去，结果连续三个 Sprint 的速度数据全是错的，规划会上没人信那张表，最后只能手工翻 issue 历史重新算。从那以后我每次关闭 Sprint 前都强制走一遍这五步，宁可慢十分钟，不再给自己留后悔药。希望帮到你。
本文还有配套的精品资源，点击获取
