Scrum
的定义
Scrum (
名词): Scrum
是一个框架，在此框架中人们可以解决复杂的自适应难题，同
时也能高效并创造性地交付可能最高价值的产品。 Scrum
是:
•
轻量的
•
易于理解的
•
难以精通的
Scrum
是一个框架，自上世纪 90
年代初以来，它就已经被应用于管理复杂产品的工作
上。Scrum
并不是一种过程、技术或决定性方法。倒不如说，它是一个框架，在此框架中
您可以使用各种不同的过程和技术。Scrum
让您的产品管理和工作技术的相对成效更加清
晰地显现出来，以便您可以持续改进产品、团队和工作环境。
Scrum
框架由 Scrum
团队以及与之相关的角色、事件、工件和规则组成。框架中的每个
部分都有其特定的目的，其对于 Scrum
的成功与使用是至关重要的。 Scrum
的规则把角色、事件和工件组织在一起，管理它们之间的关系和交互。
Scrum
的应用
Scrum
最初是为了管理和开发产品而开发的。从上世纪 90
年代初开始，Scrum
在全球范
围内已得到了广泛应用:
1.
研究与识别出可行的市场、技术和产品能力;
2.
开发产品和增强功能;
3.
产品和增强功能，频率高到一天发布多次;
4.
开发与支持云(
在线、安全、按需)
和其他运行环境来提供给产品使用;
以及， 5.
支持和更新产品。
Scrum
已被用于开发软件、硬件、嵌入式软件、交互功能网络、自动驾驶汽车、
学校、政
府、市场营销、管理组织运营，以及几乎所有我们(
作为个人和群体)
日常生活中所使用
的一切。
Scrum
运作示意图
SCRUM
框架包括3
个角色、3
个工件、5
个事件、5
个价值
3
个角色
产品负责人（Product Owner
）
Scrum Master
开发团队
3
个工件
产品Backlog
（Product Backlog
）
SprintBacklog
产品增量（Increment
）
5
个事件
Sprint
（Sprint
本身是一个事件，包括了如下4
个事件）
Sprint
计划会议（Sprint Planning Meeting
）
每日站会（Daily Scrum Meeting
）
Sprint
评审会议（Sprint Review Meeting
）
Sprint
回顾会议（Sprint Retrospective Meeting
）
5
个价值
承诺
–
愿意对目标做出承诺
专注–
把你的心思和能力都用到你承诺的工作上去
开放– Scrum
把项目中的一切开放给每个人看
尊重–
每个人都有他独特的背景和经验
勇气–
有勇气做出承诺，履行承诺，接受别人的尊重
Scrum
团队
Scrum
团队由一名产品负责人、开发团队和一名 Scrum Master
组成。Scrum
团队是跨职
能的自组织团队。自组织团队自己选择如何以最好的方式完成工作，而不是由团队之外的
人来指导。跨职能团队拥有完成工作所需的全部技能，不需要依赖团队之外的人。Scrum
团队模式仍是设计用来提供最佳的灵活性、创造力和生产力。Scrum
团队(
自身)
已经证
明，对于所有之前所述 Scrum
的应用以及任何复杂工作来说，它都是越来越有效的。
Scrum
团队迭代增量式地交付产品，籍此最大化地获得反馈的机会。增量式交付“完成”
的产品保证了一个可工作产品的潜在可用版本总是存在。
产品负责人
产品负责人的职责是将开发团队开发的产品价值最大化。如何实现这一点的方式会随着跨
组织、Scrum
团队和团队成员个体的不同而有所不同。
产品负责人是负责管理产品待办列表的唯一负责人。产品待办列表的管理包括:
清晰地表述产品待办列表项;
对产品待办列表项进行排序，使其最好地实现目标和使命;
优化开发团队所执行工作的价值;
确保产品待办列表对所有人是可见、透明和清晰的，同时显示 Scrum
团队下一步要做
的工作;
以及
确保开发团队对产品待办列表项有足够深的了解。
产品负责人可以亲自完成上述工作，或者也可以让开发团队来完成。然而无论何者，产品
负责人是负最终责任的人。
产品负责人是一个人，而不是一个委员会。产品负责人可能会通过产品待办列表展现一个
委员会的期望要求，但是想要改变产品待办列表项的优先级都必须经过产品负责人。
为保证产品负责人的工作取得成功，组织中的所有人员都必须尊重他/
她的决定。产品负
责人对产品待办列表的内容和排序的决定必须是可见的。没有人可以强迫开发团队按照另
一套需求开展工作。
开发团队
开发团队包含各种专业人员，负责在每个 Sprint
结束时交付潜在可发布并且“完成”的
产品增量。在 Sprint
评审会议上，一个“完成”增量是必需的。只有开发团队成员才能
创建增量。
开发团队由组织组建并得到授权，团队自己组织和管理他们的工作。由此产生的正面效应
能最大化开发团队的整体效率和效用。
开发团队具有下列特点:
他们是自组织的。没有人(
即使是 Scrum Master)
有权告诉开发团队应该如何把产品
待办列表变成潜在可发布的功能增量;
开发团队是跨职能的团队，团队作为一个整体，拥有创建产品增量所需的全部技能;
Scrum
不认可开发团队成员的任何头衔，不管其承担何种工作(
他们都叫开发人员)
。Scrum
不认可开发团队中所谓的“子团队”，无论其需要处理的领域是诸如测试、架构、运维或业务分析;
同时开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队。
开发团队的规模
开发团队最佳规模是足够小以保持敏捷性，同时足够大可以在 Sprint
内完成重要的工
作。少于 3
个人的开发团队，成员之间没有足够的互动，因而生产力的增长不会很大。
过小的团队在 Sprint
中可能会遭遇到技能上的约束，进而导致开发团队无法交付潜在可
发布的产品增量。超过 9
人的团队则需要过多的协调沟通工作。对经验过程而言，大型
开发团队会产生太多的复杂性而变得无用。产品负责人和 Scrum Master
角色不包含在开
发团队人数中，除非他们同时也参与执行 Sprint
待办列表中的工作。
Scrum Master
Scrum Master
负责根据 Scrum
指南中的定义来促进和支持 Scrum
。Scrum Master
通过帮
助每个人理解 Scrum
理论、实践、规则和价值来做到这一点。
Scrum Master
对 Scrum
团队而言，他/
她是一位服务型领导。Scrum Master
帮助 Scrum
团队之外的人了解他/
她如何与 Scrum
团队交互是有益的，通过改变他/
她们与 Scrum
团
队的互动方式来最大化 Scrum
团队所创造的价值。
Scrum Master
服务于产品负责人
Scrum Master
以各种方式服务于产品负责人，包括:
•
确保 Scrum
团队中的每个人都尽可能地理解目标、范围和产品域;
•
找到有效管理产品待办列表的技巧;
•
帮助 Scrum
团队理解为何需要清晰且简明的产品待办列表项;
•
理解在经验主义的环境中的产品规划
•
确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值;
•
理解并实践敏捷性;
以及，当被请求或需要时，引导 Scrum
事件。
Scrum Master
服务于开发团队
Scrum Master
以各种方式服务于开发团队，包括:
•
作为教练在自组织和跨职能方面给予开发团队以指导;
•
帮助开发团队创造高价值的产品;
•
移除开发团队工作进展中的障碍;
•
按被请求或需要时，引导 Scrum
事件;
以及在 Scrum
还未完全采纳和理解的组织环境中，作为教练指导开发团队。
Sprint
Sprint
是 Scrum
的核心，其长度(
持续时间)
为一个月或更短的限时，这段时间内构建
一个“完成”、可用的和潜在可发布的产品增量。在整个开发过程期间，Sprint
的长度保
持一致。前一个 Sprint
结束后，下一个新的 Sprint
紧接着立即开始。
Sprint
由 Sprint
计划会议、每日 Scrum
站会、开发工作、Sprint
评审会议和 Sprint
回顾
会议构成。
在 Sprint
期间:
•
不能做出有害于 Sprint
目标的改变;
•
不能降低质量的目标;
以及，
•
随着对信息掌握的增加，产品负责人与开发团队之间对范围内要做的事可以加以澄清
和重新协商。
每个 Sprint
都可以被视为一个项目，为期不超过一个月。就如同项目一样，Sprint
被用
于完成某些事情。每个 Sprint
都会有一个要构建什么的目标，还有一份设计过和灵活的
计划用来指导如何做这些事、工作内容和最终产品增量。
Sprint
的长度限制在一个月内。当 Sprint
的长度太长的话，对要构建什么的定义就有可能会改变，复杂性也有可能会增加，同时风险也有可能会增加。Sprint
通过确保至少每月
一次对达成目标的进度进行检视和适应，来实现可预测性。Sprint
同时也把风险限制在一
个月的成本上。
Sprint
计划会议
Sprint
中要做的工作在 Sprint
计划会议中来做计划。这份工作计划是由整个 Scrum
团队
共同协作完成的。
Sprint
计划会议是有时间盒限定的，以一个月的 Sprint
来说最长为 8
小时。对于较短的 Sprint
，会议时间通常会缩短。Scrum Master
要确保会议顺利举行，并且每个参会者都理
解会议的目的。Scrum Master
要教导 Scrum
团队遵守时间盒的规则。
Sprint
计划会议回答以下问题:
•
接下来的 Sprint
交付的增量中要包含什么内容?
•
要如何完成交付增量所需的工作?
话题一
:
这次
Sprint
能做什么
?
开发团队预测在这次 Sprint
中要开发的功能。产品负责人讲解 Sprint
的目标以及达成该
目标所需完成的产品待办列表项。整个 Scrum
团队协同工作来理解 Sprint
的工作。
Sprint
会议的输入是产品待办列表、最新的产品增量、开发团队在这个 Sprint
中能力的
预测以及开发团队的以往表现。开发团队自己决定选择产品待办列表项的数量。只有开发
团队可以评估接下来的 Sprint
可以完成什么工作。
在 Sprint
计划会议中，Scrum
团队还草拟一个 Sprint
目标。Sprint
目标是在这个 Sprint
通过实现产品待办列表要达到的目的，同时它也为开发团队提供指引，使得开发团队明确
开发增量的目的。
话题二
:
如何完成所选的工作
?
在设定了 Sprint
目标并选出这个 Sprint
要完成的产品待办列表项之后，开发团队将决定
如何在 Sprint
中把这些功能构建成“完成”的产品增量。这个 Sprint
中所选出的产品待
办列表项加上如何交付它们的计划称之为 Sprint
待办列表。
开发团队通常从设计整个系统开始，到如何将产品待办列表转换成可工作的产品增量所需
要的工作。工作有不同的大小，或者不同的预估工作量。然而，在 Sprint
计划会议中，
开发团队已经挑选出足够量的工作，以此来预估他们在即将到来的 Sprint
中能够完成。
在 Sprint
计划会议的最后，开发团队规划出在 Sprint
最初几天内所要做的工作，通常以
一天或更少为一个单位。开发团队自组织地领取 Sprint
待办产品列表中的工作，领取工
作在 Sprint
计划会议和 Sprint
期间按需进行。
产品负责人能够帮助解释清楚所选定的产品待办列表项，并做出权衡。如果开发团队认为
工作过多或过少，他们可以与产品负责人重新协商所选的产品待办列表项。开发团队也可
以邀请其他人员参加会议，以获得技术或领域知识方面的建议。
在 Sprint
计划会议结束时，开发团队应该能够向产品负责人和 Scrum Master
解释他们将
如何以自组织团队的形式完成 Sprint
目标并开发出预期的产品增量。
Sprint
目标
Sprint
目标是在当前 Sprint
通过实现产品待办列表要达到的目的。它为开发团队提供指
引，使得团队明确为什么要构建增量。Sprint
目标在 Sprint
计划会议中确定。Sprint
目标
为开发团队在 Sprint
中所实现的功能留有一定的弹性。所选定的产品待办列表项会提供
一个连贯一致的功能，也即是 Sprint
目标。Sprint
目标可以是任何其他的连贯性来促使
开发团队一起工作而不是分开独自做。
开发团队必须在工作中时刻谨记 Sprint
目标。为了达成 Sprint
目标，需要实现相应的功
能和实施所需的技术。如果所需工作和预期的不同，开发团队需要与产品负责人沟通协商 Sprint
待办列表的范围。
每日
Scrum
站会
每日 Scrum
站会是开发团队的一个时间盒限定为 15
分钟的事件。每日 Scrum
站会在 Sprint
的每一天都举行。在每日 Scrum
站会上，开发团队为接下来的 24
小时的工作制
定计划。通过检视上次每日 Scrum
站会以来的工作和预测即将到来的 Sprint
工作来优化
团队协作和效能。每日 Scrum
站会在同一时间同一地点举行，以便降低复杂性。
开发团队籍由每日 Scrum
站会来检视完成 Sprint
目标的进度，并检视完成 Sprint
待办
列表的工作进度趋势。每日 Scrum
站会优化了开发团队达成 Sprint
目标的可能性。每
天，开发团队应该知道如何以自组织团队来协同工作以达成 Sprint
目标，并在 Sprint
结
束时开发出预期中的增量。
会议的结构由开发团队设定。只要会议专注于达成 Sprint
目标的进展，开发团队可以采
用不同的方式进行。一些开发团队会以问题为导向来开会，有些开发团队会基于更多的讨
论来开会。以下是一个可以使用的范例:
•
昨天，我为帮助开发团队达成 Sprint
目标做了什么?
•
今天，我为帮助开发团队达成 Sprint
目标准备做什么?
Scrum Master
教导开发团队将每日 Scrum
会议时间控制在 15
分钟内。
每日 Scrum
站会是开发团队的内部会议。如果有开发团队之外的人出席会议，Scrum Master
必须确保他们不会干扰会议进行。
每日 Scrum
站会增进交流沟通、减少其他会议、发现开发过程中需要移除的障碍、突显
并促进快速地做决策、提高开发团队的认知程度。这是一个进行检视与适应的关键会议。
Sprint
评审会议
Sprint
评审会议在 Sprint
快结束时举行
，用以检视所交付的产品增量并按需调整产品待
办列表。在 Sprint
评审会议中，Scrum
团队和利益攸关者协同讨论在这次 Sprint
中所完
成的工作。根据完成情况和 Sprint
期间产品待办列表的变化，所有参会人员协同讨论接
下来可能要做的事情来优化价值。这是一个非正式会议，并不是一个进度汇报会议，演示
增量的目的是为了获取反馈并促进合作。
对于长度为一个月的 Sprint
来说，评审会议时间最长不超过 4
小时。对于较短的 Sprint
来说，会议时间通常会缩短。Scrum Master
要确保会议举行，并且每个参会者都明白会议
的目的。Scrum Master
教导每位参会者遵守时间盒的规则。
Sprint
评审会议包含以下内容:
参会者包括 Scrum
团队和产品负责人邀请的主要利益攸关者;
产品负责人说明哪些产品待办列表项已经“完成”和哪些没有“完成”;
开发团队讨论在 Sprint
期间哪些工作做的很好，遭遇到什么问题以及问题是如何解决
的;
开发团队演示“完成”的工作并解答关于所交付增量的问题;
产品负责人讨论当前的产品待办列表的情况。他/
她根据到目前为止的进度来预测可
能的目标交付日期(
如果有需要的话);
参会的所有人就下一步的工作进行探讨，这样， Sprint
评审会议就能够为接下了的
Sprint
计划会议提供有价值的输入信息;
评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变;
同时为下个预期产品功能或产品能力版本的发布评审时间表、预算、潜力和市场。
Sprint
评审会议的结果是一份修订后的产品待办列表，阐明很可能进入下个 Sprint
的产
品待办列表项。产品待办列表也有可能为了迎接新的机会而进行全局性地调整。
Sprint
回顾会议
Sprint
回顾会议是 Scrum
团队检视自身并创建下一个 Sprint
改进计划的机会。
回顾会议发生在 Sprint
评审会议结束之后，下个 Sprint
计划会议之前。对于长度为一个
月的 Sprint
来说，回顾会议时间最长不超过 3
小时。对于较短的 Sprint
来说，会议时
间通常会缩短。Scrum Master
要确保会议举行，并且每个参会者都明白会议的目的。
Scrum Master
确保会议是积极的和富有成效的。 Scrum Master
教导大家遵守时间盒的规
则。Scrum Master
对 Scrum
过程负责，作为团队的一员参加该会议。
Sprint
回顾会议的目的在于:
•
检视前一个 Sprint
中关于人、关系、过程和工具的情况如何;
•
找出并加以排序做得好的和潜在需要改进的主要方面;
同时，
•
制定改进 Scrum
团队工作方式的计划。
Scrum Master
鼓励 Scrum
团队在 Scrum
的过程框架内改进开发过程和实践，使得他们
能在下个 Sprint
中更高效更愉快。在每个 Sprint
回顾会议中，如果适用并且不与产品或
组织标准相冲突，Scrum
团队计划不同的方式通过改进工作过程或调整“
完成”
的定义来提
高产品质量。
在 Sprint
回顾会议结束时，Scrum
团队应该明确接下来的 Sprint
中需要实施的改进。在
下一个 Sprint
中实施这些改进是基于 Scrum
团队对自身的检视而做出的适当调整。虽然
改进可以在任何时间执行，但 Sprint
回顾会议提供了一个专注于检视和适应的正式机会。
Scrum
工件
Scrum
的工件以不同的方式表现工作任务和价值，可以用来提供透明以及检视和适应的机
会。Scrum
所定义的工件是特别地设计的，是为了给关键信息提供最大透明化，因此每个
人对工件都需要有相同的理解。
产品待办列表
产品待办列表是一份涵盖产品中已知所需每项内容的有序列表，它是产品需求变动的唯一
来源。产品负责人负责管理产品待办列表的内容、可用性和排序。
产品待办列表永远是不完整的。最早开发的产品待办列表列举最初所知的以及理解最透彻
的需求。产品待办列表会随着产品及其应用环境的改变而演进。产品待办列表是动态的，
需要持续更新以反映出产品需要什么来保持其适用性、竞争力和有用。如果产品存在，产
品待办列表也就同样存在。
产品待办列表列出所有的特性、功能、需求、增强和修复等对未来要发布的产品进行的更
新。产品待办列表项具有这些属性:
描述、次序、估算和价值。产品待办列表项通常包括
测试描述，将在“完成”时证明其完整性。
随着产品的使用、价值的获取和获得市场的反馈，产品待办列表会成长为更大和更详尽的
列表。因为需求永不停止改变，所以产品待办列表就如一份活的工件。业务需求、市场形
势或者技术的变化都会引起产品待办列表的改变。
多个 Scrum
团队常常会一起参与对同一产品的开发。一个产品只有一个产品待办列表用
于描述下一步产品开发工作。那么这就可能需要使用能够对产品待办列表项进行分组的属性。
产品待办列表精化指的是为产品待办列表项增添细节、估算和排序的动作。这是一个持续
的过程，产品负责人和开发团队协同工作在产品待办列表项的细节上。在产品待办列表精
化过程中，产品待办列表项被重新评审和修改。Scrum
团队决定如何来完成精化以及何时
来完成。精化的工作通常占用开发团队不超过 10%
的产能。然而，产品负责人或者其他
人在产品负责人的斟酌下，产品待办列表项可以在任何时间来更新。
排序越高的产品待办列表项通常比排序低的更清晰同时包含更多细节。根据更清晰的内容
和更详尽的细节信息就能做出更为准确的估算;
同样，排序越低，则细节信息越少。产品
待办列表项中那些即将会占用开发团队下一个 Sprint
大部分时间的项会被加以精化，因
此，任一产品待办列表项都能够在 Sprint
的时间盒期限内适当地“完成”。这些能够被
开发团队在一个 Sprint
中“完成”的产品待办列表项称为“准备就绪”，它们将作为 Sprint
计划会议中的待选产品列表项。产品待办列表项的足够透明程度通常要经过上述的
精化活动来获得。
监控目标实现的进度
开发团队负责所有估算工作。产品负责人可以通过帮助开发团队更好地理解需求，并根据
情况权衡取舍来影响他们，但是最终估算是由开发团队决定的。
在任何时刻，达成目标的剩余工作是可以累计的。产品负责人至少在每个 Sprint
评审会
议中都必须跟踪剩余工作总量。产品负责人比较这次的剩余工作量与之前 Sprint
评审会议时的剩余工作量，来评估在期望的时间点达成目标的进度。这个信息对所有的利益攸关
者都是透明的。
各种不同趋势走向的实践已经被使用在预测进度方面，例如，燃尽图(burn-downs)
、燃
烧图(burn-ups)
或者累积流图(cumulative flows)
。这些工具都被证实是有用的。然
而，它们并不能用来取代经验主义的重要性。在复杂的环境中，未来将要发生的事是无法
预知的。只有已经发生的事情才能用来做前瞻性的决策。
Sprint
待办列表
Sprint
待办列表是一组为当前 Sprint
选出的产品待办列表项，同时加上交付产品增量和
实现 Sprint
目标的计划。Sprint
待办列表是开发团队对于下一个产品增量所需的那些功
能以及交付那些功能到“完成”的增量中所需工作的预测。
Sprint
产品待办列表将开发团队用来达成 Sprint
目标的所有工作变得清晰可见。为了确
保持续改进，它至少包括一项在前次回顾会议中确定下来的高优先级的过程改进。
Sprint
产品待办列表是拥有足够细节的计划，任何进度的变化可以在每日 Scrum
站会中
清晰地看到。开发团队在 Sprint
期间修改 Sprint
待办列表，使得 Sprint
待办列表在 Sprint
期间涌现。涌现发生在开发团队按计划开展工作并学习到更多的关于哪些工作是达
成 Sprint
目标所必需的工作时。
当新工作出现时，开发团队需要将其加入到 Sprint
待办列表中去。随着工作的执行或完
成，剩余的工作量被估算并更新。当计划中的某个部分失去开发意义，就可以将其移除。
在 Sprint
期间，只有开发团队可以改变 Sprint
待办列表。Sprint
待办列表是高度可见
的，是对开发团队计划在当前 Sprint
内工作完成情况的实时反映，该列表由开发团队全
权负责。
监控
Sprint
进度
在 Sprint
的任何时间点都可以计算 Sprint
待办列表中所有剩余工作的总和。开发团队至
少在每日 Scrum
站会时跟踪剩余工作的总和，预测达成 Sprint
目标的可能性。通过在 Sprint
中不断跟踪剩余的工作量，开发团队可以管理自己的进度。
增量
增量是一个 Sprint
完成的所有产品待办列表项的总和，以及之前所有 Sprint
所产生的增
量的价值总和。在 Sprint
的最后，新的增量必须是“完成”的，这意味着它必须可用并
且达到了 Scrum
团队“完成”的定义的标准。增量是在 Sprint
结束时支持经验主义的、
可检视的和已完成的产品组成部分。增量是迈向愿景或目标的一步。无论产品负责人是否
决定发布它，增量必须可用。
看板
看板模型要素
流程有一个个步骤组成，每个步骤对应一个角色的工作
工作项在各角色直接移交，经过每一个步骤直到完成
每个步骤有2
个泳道，一个就绪一个进行，未开始工作都在就绪中，
就绪对垒中的任务需要按照优先级排列
也可以使用进行中和完成来表示
研发看板设计
任务卡片
缺陷
阻碍发布的缺陷
这类缺陷在开发完成后被发现，需要修复才能发版本，优先级高，通过粘贴在工作卡片上的红色卡片体现，这也强调了改工作还没有开发完的事实
对于被修复的缺陷有2
中处理方式
- 在卡片上用粗笔划去，并保留在工作项上，随着工作项卡片的变动而变动
- 将其从工作项上取下来
让缺陷始终留在工作上的做法能够一目了然的看到迭代内完成整理项目的质量，始终保持缺陷与工作卡的关系能清晰的区分那些是已经被修复了的。但是这样做可能会产生较多的过期信息和视觉上的噪音，让其它的更重要的信息不够突出
如果取下来可以屏蔽噪音，但是失去了物理关联性
是否取下来取决于是否想看历史缺陷，看板可视化的原则就是用丑陋的看板表示丑陋的事情。
隐藏看板的过期信息
后期发现的或者不阻碍发布的缺陷，单独写在卡片上
生产缺陷：
同上
可视化角色
在泳道的开始贴上大头贴。
暴露多任务
清楚的反应出有多少人，以及每个人都在做什么，是否有多任务，是可视化的一个重要目的
每个人仅用一个卡片来代表，且仅仅出现在自己的队列中
工作项卡片重叠表示一个人的多任务
为进行中队列多设置空间
多任务不要在泳道上规则排，要重叠在一起，表示工作状态
多任务大多数因为当前任务被阻塞了、依赖团队以外的人员支持，或者是被一个优先级更高的工作打断。
对于阻塞的情况，通过一个便签说明任务被阻塞的原因，这样做有几个好处
便于其他人了解当前的阻塞任务，提供帮助或者管理跟进
便于在站会中及时解决问题，当站会中发现没有变迁说明多任务卡片时，现场添加。
提醒自己避免多任务情况
视觉上让问题突显，更容易被关注
绿色或者蓝色有生气，表示有价值的业务需求
白色显的中立表示没有直接业务价值的技术任务
粉色或者红色表示缺陷
黄色表示阻碍和问题
可视化原则
在看板或者便签上用一直的用色突出分类