1. 产品列表
产品列表由各个待办事项组成，每个待办事项称之为产品列表条目，按照性质区分，可以把产品列表条目大致分为：经常写成用户故事形式的特性，缺陷，技术工作和知识获取。我们使用产品列表来按照优先级排序预期产品的功能，把所了解的以什么顺序构建什么特性等这些信息都集中到产品列表中，并且与团队共享。在Scrum当中，产品列表是最为核心的工件，也是被应用最广泛的工件。
一般任务板需要实现以下几个功能: 显示信息， 属性可编辑，用户权限管理，任务板自定义配置。（下图是一个可以参考的任务板）
每个需要实现的史诗级用户故事需要的实现的具体功能分别创建用户故事并且填写具体额达描述，并且最后要按照你的对用户故事完成顺序的优先级把用户故事排列好。并且对产品列表条目的大小做好评估
（这里有两种实践方式：1. T-shirt Size, 将用户故事分为S, M, L, XL. 2. Planning Card：参考：Planning Cards Help Agile Teams Estimate Work）
梳理产品列表是一个持续不断， 需要合作完成的工作，产品负责人牵头，包括内外部干系人中的主要参与者， ScrumMaster和开发团队在内。经过梳理后，团队完成了对产品列表优先级和大小的估算。梳理会议一般是在计划会议之前进行的，经常上一个冲刺的过程中，就会召开为下一个冲刺做准备的梳理会议。原则上，梳理用户故事列表是一个不间断的行为，因此在冲刺开始之前做一次梳理，然后根据实际需要，Scrum团队需要不停地做梳理。
当中针对产品列表的优先级排序时，可以参照MoSCoW的技术它将需要做的产品功能分成四类：Must Have (必须有的功能)，Should Have （应该有的功能），Could Have(可以有的功能)和 Would Have(也许有的功能)，通过这个技术，可以将产品列表中的用户故事强行分成4个级别，有助你集中资源集中完成Must Have和 Should Have的用户故事。
产品列表小结：
产品列表应该具有如下特点。
1. 详略得当： 马上要做的条目要详细描述，段时间内不做的内容粗略。
2. 涌现的：只要有正在开发或维护的产品，产品列表就永远不会完成或冻结。它会根据不断涌入的，具体的，有经济价值的信息持续更新。
3. 做过估算的： 每个产品列表条目都要有大小估算，相当于开发这个条目需要完成多少工作。
4. 排列优先顺序的： 对短期内要做的几个冲刺要仔细排好优先顺序。但是对于短期内不做的条目，除了给一个大致的优先级，其他任务工作都是不值得做的。
2.Sprint代办列表
Sprint列表是团队当前Sprint的任务清单。和产品列表不一样，它的寿命是有限的，仅在一个Sprint的时间里存活。它里面包含所有团队已承诺的故事以及相关联的任务，以及此外的附加工作，例如，在回顾会议中所发现的团队改进任务，团队计划要在当前Sprint完成。Sprint列表在Sprint规划会议中产生一旦Sprint规划会议结束，产品负责人就不能再修改Sprint列表的故事清单了。这是Scrum中业务方和开发团队之间的基本协议，每次Sprint开始前，业务方都可以改变方向，然而Sprint开始以后，团队则会专注于他们所承诺完成的故事。改变这个已承诺的故事清单只有一个方式，就是由干这个活的团队成员提出变更需求。也许团队发现他们能比最初设想的做更多的活，也或许他们无法交付所有已经承诺的故事。遇到这种情况，产品负责人将和团队一起修改Sprint列表中的故事清单。产品列表是固定不变的，与之相比，Sprint列表则是Sprint过程中一直都在变化的。团队一旦发现想要交付的已经承诺的故事还有些新的任务需要完成，就会把他们添加进Sprint列表。有时候团队也会发现某个现有任务已经毫无意义那他们就会从Sprint列表中把它剔除掉。
在实际的工作中，我们就是在计划会议当中将计划做的故事从产品列表拖拽到Sprint待办列表当中（JIRA支持从产品列表直接拖拽故事到Sprint待办列表）。在这之后，我们需要为每个用户故事创建相应的任务。
用户故事是一种优秀的工具，可以承载客户或用户价值的条目贯穿于Scrum的价值创造流程。然而，如果故事的大小都一样，就很难做好概要计划并体会到逐步细化的好处。例如，如果在冲刺阶段使用的故事太多，太小，是无法为概要产品规划和发布规划提供支持的。在这些层级上，我们就会淹没在大量无关的细节中。因此，根据详略程度，用户故事是分层的。最大的用户故事约为几个月的大小，可以跨一整个或多个版本，就是我没那之前说的Epic（史诗级故事）。第二个级别的故事的大小通常以周为单位，对单个冲刺来说还是有点儿大，有些团队称之为特性。最小的用户故事就是我们通常说的’故事‘，或者冲刺故事，它足够小，可以放入一个冲刺完成。任务处于故事下面一级，通常是一个人独立完成的工作，或者也有可能两个人结对完成。完成任务所需要的时间一般以小时记。在任务这一级，我们要详细地说明如何构建而非构建什么（以Epic，特性和故事为代表）。任务不是故事，因此我们在写故事的时候必须要避免任务级的细节。
Sprint待办列表小结：
1. Sprint列表是一组为当前Sprint选出的产品待办列表项，同时加上交付产品增量和实现Sprint目标的计划。
2. Sprint列表是开发团队对于下一个产品增量所需的功能以及交付这些功能到“完成”的增量中所需的工作的预测。
3.为了确保持续改进，Sprint列表至少包含一项在前次回顾会议中确定下来的高优先级的过程改进。
4.Sprint列表是拥有足够细节的计划，任务进度上的变化可以在每日展会中清晰的看到。开发团队在Sprint期间修改Sprint列表使得列表在Sprint期间涌现（根基不断涌现的，具有经济价值的信息持续更新）。
5.在Sprint期间只有开发团队可以改变Sprint列表。
6.Sprint列表是高度可见的，是对开发团队计划在当前Sprint内工作完成情况的实际反映，由开发团队全权负责。
3. 完成的定义
Scrum里有一个重要的工件叫做“完成的定义”，什么时候算是冲刺完成了？
1.冲刺的时间盒到了，冲刺就必须结束。 2.每个冲刺的结果是一个潜在可发布的产品增量。这并不意味着增量必须交付给用户，交付是一个业务策略，和软件开发不一定是同一个节奏。在有些组织里，每个冲刺结束时都进行交付不一定能多带来什么经济利益。 3.潜在可发布反映了冲刺中构建的产品已经正真完成，意味着如果在业务上需要，就可以交付。为了确定开发出来的东西是潜在可发布的，Scrum团队必须有一个明确的定义，大家一致同意的完成的定义。
对于完成的定义，有时候大家讨论起来经常弯弯绕，不停地兜兜转转，但就是没有结论，最后各方都沮丧甚至愤愤然不欢而散。在“过去的日子里”，程序员和测试人员在讨论质量问题时候发生的这样的争吵数不胜数。程序员坚持自己的代码完全满足需要;测试人员则气得掉头发，说事实正好相反谁是对的呢？都不对！问题在于构成足够质量标准的规则没有清楚的定义或者没有进行很好的沟通。如果完成的定义是大家共同讨论定制的，就能极大地避免这些争吵的发生。完成的定义成为一个指导开发工作的协议，清楚列出一项任务需要完成哪些工作之后才可以被归为完成。
但是在最初定义DoD（对软件有价值的活动的清单）的时候还是要现实甚至是保守一些的。一定要根据团队的能力和期望来定制。而且DoD也会随着项目的推进会根据实际情况相应的调整拥抱敏捷。此外很多团队会将非功能性的需求写进DoD,比如下面这些：
完成的定义---非功能性需求
可伸缩性： 规模必须能扩充到同时支持2000个用户。
可移植性： 使用的任何第三方技术都必须是跨平台的。
可维护性： 所有模块都需要的保持清楚的模块化设计。
安全性：必须通过具体的安全渗透测试。
下面是一个“完成定义的”样例：
完成的定义小结：
完成的的定义具有以下的特点。 1. 完成的定义可以随着时间演变。 2. 完成的定义和接收标准不同（当某个“接受标准”里的需求适合于所有的用户故事，那么它就是完成标准里的一项的；但如果该需求只是适用于所有用户故事的一个子集，那么它就是这个用户故事子集里的故事的验收标准）。 3. 完成的定义可以是多个不同层面的（任务层面， 用户故事层面，交付层面）。 4. 完成的定义里会包含一些限制因素（可移植性，可维护性，安全性，可扩展性，互相操作性）。
4. 监测
Sprint然尽图和交付燃尽图
Sprint然尽图
Sprint燃尽图用于显示当前冲刺剩余工作量的变化。增加或者完成任务以后，团队成员会更新图标（JIRA工具会自动更新），以体现剩余的工作量（工作量可以用任务小时，任务点或者任务数量来表示）。Sprint燃尽图的目的在于，通过它团队能够看清楚情况并且指导自己能否交付迭代中已经承诺的全部。如果能做到，那很棒！如果做不到，这个图标可以帮助团队尽早发现问题，这样就还有时间进行调整，如果团队发现有些故事已经无法完成，也能立刻让产品负责人知道。这样负责人可能会选择放弃Sprint中某个故事，也可能会选择缩小一个或几个故事的范围，直到团队能完成剩下的部分为止。如果团队发觉他们将提早完成所有的故事，那么就可以找产品负责人再要一个故事继续开发。
团队工作刚开始的时候，他们会发现还需要完成一些新的任务，这是正常现象。发现这些任务之后，就要估计他们的大小，还要加入到Sprint列表当中，由此带来的增长会体现Sprint燃尽图上。大多数团队发现Sprint到1/3的时候，燃尽图又会掉头回来继续向下。Sprint进行当中发现更多工作成了一种模式，一些团队刚开始会被吓到，但很快就开始意识到这就是正常Sprint燃尽图的模样，刚开始向上翘，随后开始正真转为下降趋势。
我这边画的比较粗糙，想看更多Sprint燃尽图可以查看：燃尽图（Burndown Chart）
交付燃尽图
交付燃尽图便于产品负责人跟踪发布剩余工作随时间变化的过程。通常情况下，我们会使用Sprint作为时间轴增量，剩余故事点数作纵轴。不同的下降趋势反映了单位时间段内所完成点数的自然变化。故事点的增长会形成发布燃尽图上的钉状突起，这样的情况应该少出现。在走向发布的过程中，你会想看到下行的剩余工作趋势线。
如果发生那种钉状凸起，怎么才能预测我们最后能在哪个Sprint发布呢？可以参考下面一个更加复杂的燃尽图。
浅绿色的柱状代表，这个目标完成了的任务点数，所以前面加了个减号撒；
浅蓝色的柱状代表，在这个目标开启之前就存在的任务点数，在这个目标结束时还剩下多少；
深蓝色的柱状代表，在这个目标开启后到下个目标开启前这段时间，版本中增加了多少任务点数，所以用加号，在当前没有开启的目标甚至没有目标的情况下，增加的点数就都算在上一个目标头上啦。
两条预测线，上面那条的由来是，浅蓝色柱状的顶部中点，用最小二乘法计算的拟合直线；下面那条则是，深蓝色柱状的底部中点，用最小二乘法计算的拟合直线。两条线斜率的意义是，每个目标任务点数完成的速率和任务点数新增的速率。
两条预测线的交点对应的横坐标代表，这个版本预计会在哪个冲刺目标内完成。
大部分在线工具（如JIRA）都支持这个交付燃尽图的绘制。如果对这个图的细节感兴趣可以去看看：交付燃尽图（Release Burndown）
监测小结：
5.常见的问题
5.1 谁负责产品列表， 谁负责Sprint待办列表
产品列表由产品负责人负责管理并对它拥有绝对的权利。但是，这并不代表只有产品负责人才可以向产品列表中添加和修改内容。
例如，问题，技术相关的工作就经常需要来创建相应的条目。对于用户故事来说，也经常需要团队成员去维护相应条目。
因此，我们说产品负责人管理产品列表，但维护产品列表的责任团队成员人人有之。至于每个团队的成员如何帮助产品负责人维护产品列表，要看产品负责人给团队成员的授权而定。
关于Sprint待办列表，它是在每个冲刺的计划会议当中产生的。在进入Sprint阶段以后，团队成员负责维护和更新Sprint待办列表。因此，Sprint待办列表是属于团队的。
5.2 产品列表的优先级如何定制
产品列表的优先级是产品负责人根据公司更高层面的策略制定的。通常情况下，对于Scrum小组来说，他们的产品列表优先级要服从于整个产品，甚至是产品集的优先级（产品组合规划 -> 产品规划 -> 版本规划 -> 冲刺规划）。
5.3 什么是DOR
Definition of Ready 即准备就绪的定义。DoR就是一个类似于DoD的列表。排序越高的产品待办列表项通常比排序越低的更清晰，同时包含更多细节。
根据更清晰的内容和更详尽的细节信息就能组出更为准备的估算;同样，排序越低，则细节信息越少。产品待办列表项中那些即将会占用开发团队下一个Sprint大部分时间的项将会被加以精化，
因此，任一产品待办列表项都能够在Sprint的时间盒期限内适当地“完成”。这些能够被开发团队在一个Sprint中“完成”的产品待办列表项称为“准备就绪”，
它们将作为Sprint计划会议中的待选产品列表项。产品待办列表项的足够透明程度通常要经过上述的精化活动来获得。如果满足DoR定义,
列表中规定的产品待办列表项可以放入到Sprint待选产品列表里。如果不满足DoR的定义，则不可以放入Sprint待选产品列表当中。
5.4 敏捷了还需要文档吗
敏捷要做的就是减少浪费，以便能按照项目的特点灵活选择文档的数量和形式，在过度设计和返工之间寻找到平衡。也就是说，每个项目都要根据自己的特点，
选择合适的形式和内容来写文档。例如在大多数项目中，设计文档，接口文档是一定要写的，但是有些需求文档也许就不用刻意写了，
JIRA或者其它用来整理用户故事的工具里的信息就已经足够了。
5.5 Scrum管理产品列表，冲刺待办列表，需要什么工具
1. 你需要一个任务板，不同颜色的便签纸，白板笔。如果不是远程团队，那么就请在办公室团队的为止准备一个实体白板来作为任务板 2. 你还需要管理产品列表和冲刺待办列表的工具。简单到一个Excel表格，复杂到JIRA系统，只要可以帮助管理你的待办事项就没问题。
5.6 什么时候梳理产品列表，谁梳理产品列表，怎么梳理
产品列表的梳理是包括产品负责人，ScrumMaster, 研发团队在内的整个团队的责任。梳理产品列表的形式可以是多样的，根据团队的成熟度和产品的特点不同，每个团队都可以选择自己喜欢的梳理方式。
例如，对于不成熟的团队，如果团队成员还没有形成定时梳理列表的习惯，那么由ScrumMaster定期组织梳理会议的方式就比较合适。
如果团队很成熟，成员可以自发的定时梳理产品列表，那么就不用组织什么专门的会议。
如果团队跨国家，跨地区，例如产品负责人在美国，研发团队在深圳，那么邮件沟通和电话或视频会议的形式就更加合适了。
团队可以选择梳理产品列表的时间，只要这个时间是在计划会议之前并且团队有充足的时间进行梳理和调整就可以。
5.7 需要开产品列表梳理会议吗
产品列表梳理会议不是Scrum的标准活动，也就是说这个会议不是必需的。但是大部分的Scrum团队都会选择使用产品列表梳理会议。
当然，对于非常成熟的团队，他们可能会因为对产品的了解以及团队成员之间频繁的沟通而不必非要组织专门的梳理会议。
另外一种情况是转型初期的团队，他们可能会期许产品负责人提供完备的文档，团队之间还没有形成良好的互动，
如果ScrumMaster不够强势的话，产品梳理会议也会被忽略。对于上述两种情况，第一种非常健康，梳理会议不是必须的;第二种就不健康，建议团队考虑梳理会议。
5.8 Scrum团队跟踪个人完成的任务吗
Scrum团队强调团队作战。跟踪个人的KPI指标有点违背这个原则。Scrum的各种监测图都是以团队为单位的。没见过有哪个监测工具是统计团队中个人的工作绩效的。
5.9 监测的结果可以用来比较不同的Scrum团队之间的绩效差距吗
每个团队负责的功能和对故事点的理解以及团队成员数量都有可能不同，因此不能直接将团队的工作量进行比较（即使是按照团队成员数量比例进行计算后的比较也是不公平的）。
但是，对于一个团队能否每个迭代都完成承诺，一个团队处理单个任务的时间这样的指标是可以进行比较的。监测的结果重在协助团队进行自我管理。