如何可视化需求状态和团队状态？

我们团队在实践 Scrum，每两周一个 Sprint，一个 Sprint 有 100 多个需求。

我们把几十名技术人员，按前端、测试等不同职能，划分为多个3-10人的小团队。然后围绕业务，按职能矩阵的方式，组成了几个 Scrum 团队。每个 Scrum 团队同时负责多款产品。

现在遇到的困难是，需求管理、团队管理的成本都很高，整个大团队的进展没办法直观、及时获取到。

如何及时直观地了解需求状态和团队状态？

需求状态包括：什么时间交付哪些特性，哪些已经完成了，哪些正在开发中，哪些被阻塞了等。

这个话题涉及 Scrum 的五个价值观之一「开放」，开放包括组织层面的开放和个人层面的开放。

组织层面，将所有的信息可视化出来，包括用户需求，干系人期望，交付计划，项目进度，用户反馈等。打造一个「信息化工作场所」，任何人走入这个场所都可以快速获取到想要的信息。

如何可视化需求状态？

在实施 Scrum 时我们通常会用「用户故事 User Story」来描述产品需求，用「产品待办列表 Product Backlog」来组织「用户故事」。可是，在一个个迭代中，不断地完成一些需求，又新增一些需求，日复一日，好像没有尽头。

如何可视化团队状态？

我们可以用状态墙可视化项目状态，物理的或电子的都可以。

通过在需求卡片上贴头像的方式，可以直观地显示谁在做什么事。通过设置 WIP Limit，可以直观地显示出团队的瓶颈。想知道谁被阻塞了，可以增加一个 Block 的状态来表示。总之，你可以通过自定义来扩展状态墙呈现的信息。

但是，不管用物理墙还是电子墙，都可能会遇到状态更新不及时的问题。怎么解决呢？

从机制上，在站会前或站会中更新状态墙，起码可以保证状态墙能按天的节奏更新。

但更重要的是要找出为什么大家不愿更新状态？是不是没有动机？为什么不能坚持更新？是不是没有动力？

换位思考一下，做了这个事对我没什么好处，不做这个事对我没什么坏处，那我为什么要做呢？

说完了组织层面的开放，来说说个人层面的开放。

总结

我们可以用「用户故事地图」和「项目状态墙」来可视化需求状态和团队状态。

引入一个实践时，给团队讲清楚这个实践的价值，达成团队共识，约定不执行的惩罚措施（比如请所有人喝酸奶），在回顾会议中讨论是保留，改进还是放弃。