限定工作进度
一个拥有五名成员的开发团队已经使用Scrum开发了12周，完成了3个Sprint迭代开发，每个迭代开发历时4周。虽然所产生的增量比在执行Scrum之前开发的软件有更高的质量，但看起来完成的工作任务还是比较少，并且开发团队成员仍然没有很好的在一起协同工作。Scrum每日站立会议能够对团队成员的工作进行一些提醒，但是团队中的每个人其实都在孤立地工作，只关注他或她自己的任务，这种情况没有得到改善。
在Sprint计划中，开发团队创建了一个“待办事项”列表，列出了为Sprint提供的每个Product Backlog项目所需的工作。这种技术在Sprint的计划过程中创建了一个Sprint Backlog，并在整个Sprint中对开发团队的进度进行追踪。
开发团队使用在开发团队工作区墙上的可视化的任务板来跟踪整个Sprint中的任务进度。在最后一个Sprint中，Scrum Master每天在每日Scrum站立会议之前拍下可视化任务版的照片。一些照片如下所示：
Scrum Master与开发团队共享这些照片。有些事情是显而易见的，例如：
• 在开发团队中有更多的任务在不断进行。
• 在第二天，一个开发人员把所有功能C的任务转化为“正在进行”的状态，并将它们保留在Sprint迭代周期中完成。
• 在Sprint结束时功能B还没有开发，Sprint并没有完成。
• 功能C在整个Sprint中进行开发，但没有完成。开发者在开发功能C时在出现问题时缺乏帮助，并且表现的有些沮丧。尽管她在每日例会中微妙的暗示需要获得帮助，但是并没有获得需要的帮助，因为其他的团队成员都专注于自己的工作并没有感到需要对功能C负责。
• 功能被放置在Sprint的积压优先顺序在Sprint的规划和产品拥有者感到非常失望，Feature B没有在冲刺完成，因为它被命令高于其他功能交付。
• 一些功能是在一次进步，导致非常不同的部分代码，同时改变所有。在冲刺过程中，这导致了一些开发失败和返工，因为开发人员在不知不觉中影响了彼此的代码。
精益方法
在Sprint回顾中，Scrum Master解释了将在开发团队中尝试WIP限制的技术想法。开发团队决定在下一个Sprint中减少WIP并实施三个新的规则：
1、从上到下实现Sprint Backlog。
2、一次开发不超过3个Sprint Backlog Items。如果只有1/4的Sprint Backlog Item在开发中，团队将暂停工作来讨论在开发工作存在什么瓶颈导致进度缓慢。
Scrum Master在下一次Sprint中再次展示照片。下面有几张照片：
在Sprint回顾会议中，这些照片再次分享给开发团队，他们在最近的Sprint中对如何做出改变进行了观察：
1、开发团队成员共同完成了更复杂的Sprint Backlog Items。虽然在工作中有时会有不同的意见，但是不同的意见都得到解决，团队取得了更快的进展。
2、开发团队成员开始学习他们以前没有关注的产品功能。每个人都对产品整体拥有一种集体感觉。这是对以前的做法，个人只专注于功能，他们理解了鲜明的救济。
3、立即在代码的许多不同领域协调变化的复杂性显著降低。事实上，这么多，开发团队的生产力显着增加。
4、虽然功能E没有在Sprint完成，交付的所有功能都比功能E更高优先级产品所有者很高兴，并决定将增量的客户端，即使没有这个低优先级的功能。
连载（三）