1、从工作流到看板
上一篇介绍了 Jira 的工作流，它定义了 Issue 的状态流转规则。而看板（Board） 则是将工作流可视化的载体——把 Issue 以卡片形式展示在不同的状态列中，让团队一眼就能看到工作进展。
Jira 支持两种看板模式：
- Scrum 看板：面向迭代式开发，有 Sprint、待办事项列表（Backlog）、燃尽图
- Kanban 看板：面向持续流动式管理，强调在制品限制（WIP）
本文聚焦 Scrum 看板，这是需求管理中最常用的模式。
2、Scrum 核心概念
在深入看板之前，先理清 Scrum 的几个关键概念：
| 概念 | 说明 |
|---|---|
| Product Backlog（产品待办列表） | 所有待完成工作的有序列表，由产品负责人维护 |
| Sprint（迭代） | 固定时间周期（通常 1-4 周），团队承诺在此期间完成一组工作 |
| Sprint Backlog（迭代待办列表） | 当前 Sprint 中计划完成的 Issue 列表 |
| Story Point（故事点） | 相对估算单位，用于衡量工作量而非时间 |
| Velocity（速率） | 团队每个 Sprint 能完成的故事点总数 |
| Sprint Goal（迭代目标） | 当前 Sprint 要达成的业务目标 |
3、Backlog 管理
Backlog 是需求管理的核心工作区。在 Jira 的 Backlog 视图中，所有未进入 Sprint 的 Issue 都列在这里。
Backlog 优先级排序
Backlog 不是一个随意的列表，而是一个按优先级排序的队列：
Backlog（从上到下，优先级递减）
Story: 用户登录功能（P0） ← 最高优先级
Story: 首页改版（P0）
Story: 搜索功能（P1）
Bug: 修复订单金额计算（P1）
Story: 用户反馈入口（P2）
Story: 数据导出功能（P3） ← 最低优先级
...
排序原则：
- P0：核心功能或阻塞性问题，必须尽快处理
- P1：重要功能，当前版本需要完成
- P2：需要但非紧急
- P3：锦上添花，有资源再做
Jira 支持拖拽排序，产品负责人可以随时调整优先级。
创建 Epic 和 Story
在 Backlog 中，Epic 和 Story 的关系直观可见：
Epic: 用户中心改版
├── Story: 用户注册流程优化
├── Story: 个人资料编辑页
├── Story: 头像上传功能
└── Story: 账户安全设置
Epic: 数据看板
├── Story: 销售数据概览
├── Story: 用户行为分析
└── Story: 报表导出
Epic 面板可以帮助团队聚焦当前最重要的功能模块。
4、Sprint 管理
创建 Sprint
从 Backlog 中选中需要在本 Sprint 完成的 Issue，拖入 Sprint 区域即可创建一个 Sprint：
Backlog Sprint 1 (2周, 目标: 用户中心核心功能上线)
───────────────── ─────────────────
Story: 搜索功能 (P1) Story: 用户登录功能 (P0) 5 pts
Story：用户反馈入口 (P2) Story: 首页改版 (P0) 8 pts
... Story: 用户注册流程优化 (P1) 3 pts
Story: 修复订单金额计算 (P1) 2 pts
─────────────────────────────────────
Total: 18 pts (预估速率: 20 pts)
估算故事点
故事点不是工时，而是相对复杂度：
- 1 点：简单改动，半小时能搞定
- 3 点：一般功能，半天到一天
- 5 点：中等功能，需要 1-2 天
- 8 点：复杂功能，需要 2-3 天
- 13 点：大型功能，需要拆分
一个常见的做法是用计划扑克：团队成员各自给出估算值，差异大的讨论后重新估算，直到趋于一致。
Sprint 容量规划
Sprint 容量 = 团队速率 × 可用天数比例
例：团队速率 30 pts/Sprint，本 Sprint 有人休假
可用容量 = 30 × 0.85 = 25 pts
首次使用 Scrum 的团队没有历史速率数据，建议前 2-3 个 Sprint 保守估算，逐步校准。
5、看板视图
进入 Sprint 后，看板以列的形式展示 Issue 在不同状态中的分布：
┌──────────────────────────────────────────────────────────────────────────────────┐
│ To Do In Progress In Review Testing Done │
├─────────────┬────────────────┬────────────────┬──────────────┬─────────────────┤
│ PROJ-12 │ PROJ-15 │ PROJ-17 │ PROJ-18 │ PROJ-10 │
│ 搜索功能 │ 用户登录 │ 首页改版 │ 订单Bug │ 注册流程 │
│ 5 pts │ 5 pts │ 8 pts │ 2 pts │ 3 pts │
├─────────────┼────────────────┼────────────────┼──────────────┼─────────────────┤
│ PROJ-14 │ PROJ-16 │ │ │ │
│ 数据看板 │ 图片上传 │ │ │ │
│ 3 pts │ 3 pts │ │ │ │
└─────────────┴────────────────┴────────────────┴──────────────┴─────────────────┘
看板的核心价值：
- 可视化瓶颈：In Review 列堆积说明审查速度跟不上开发速度
- 发现阻塞：Issue 长时间停在一列不动，需要关注
- 每日站会：团队围绕看板同步进展，而不是汇报状态
每日站会
围绕看板的标准站会流程（每人不超过 1 分钟）：
- 我昨天做了什么？（看 Done 列的卡片）
- 我今天要做什么？（移卡片到 In Progress）
- 我遇到什么阻碍？（标记阻塞或请求帮助）
6、Sprint 报告
燃尽图（Burndown Chart）
燃尽图是 Sprint 管理的核心图表，横轴是时间，纵轴是剩余工作量：
故事点
│
20│●
│ ●
15│ ●
│ ●
10│ ●
│ ●
5│ ●
│ ●────●
0│____________________________ 时间
Day1 Day3 Day5 Day7 Day9
- 实际线在参考线下方 = 进度超前
- 实际线在参考线上方 = 进度落后，需要关注
Sprint Report
Sprint 结束后，Jira 自动生成报告，包含：
- 计划完成 vs 实际完成的 Issue
- 新增/移除的 Issue
- 完成率百分比
这些数据用于 Sprint 回顾会议（Retrospective），帮助团队持续改进。
7、总结
Scrum 看板是 Jira 最核心的需求管理工具。从 Backlog 排序到 Sprint 规划，从每日站会到 Sprint 回顾，Jira 为 Scrum 的每个环节提供了支撑。
几点实践建议：
- Backlog 要持续梳理，不要等 Sprint 开始时才匆忙排期
- 故事点要团队一起估，不要一个人拍
- 燃尽图是参考不是考核——关注趋势而非绝对值
下一篇，我们来聊聊 Jira 的查询和过滤器——如何在大量 Issue 中快速找到你想要的信息。
每天前进一小步，就是一个新的高度！