01 笨重的产品待办列表是敏捷的劲敌
你能立刻说出「敏捷」的含义吗？
一千个人眼中有一千个哈姆雷特，而我的理解是：敏捷要更快地向用户和业务提供价值。
对于抽象的「价值」，大家或许也会有不同的解读。于我而言，「提供价值」意味着在帮助用户解决问题的同时，为业务带来回报
追本溯源，敏捷强调拥抱变化，在变化中学习。我们应该简单地创建假设、验证假设、学习、检查并调整。这听上去并不复杂，但不知何故，很多人都把它变得无比复杂，包括我自己。
庞大的、笨重的产品待办列表恰恰是敏捷的反面。我猜你可能会反驳说自己很敏捷，但你是不是
- 让事项在产品待办列表中呆了很多年？
- 不敢删除任何待办事项，唯恐惹恼干系人？
- 同开发人员一起浪费大量时间处理一些永远不被排进迭代的需求？
我认为，任何有超过三个迭代工作量的产品待办列表都是笨重的。如果产品待办事项的数量比 Scrum 团队几个迭代的工作量还要多，那就说明团队当前「拥抱计划 > 拥抱变化」。那这到底是敏捷呢？还是瀑布呢？
要想实现价值，就必须维护一个精益的产品待办列表。不要被计划的假象所迷惑。
02 大胆地删除产品待办事项
无条件地向利益相关者承诺交付，美其名曰「客户至上」；但事实上，在现存的所有产品待办事项中，有近乎一半的待办毫无价值 —— 它们始终在待办列表中占有一席之地，被「计划中」完美掩护。产品负责人换了一个又一个，它们却一直没有被交付和满足。
一个无限制的、庞大而笨重的待办清单让我们永远无法兑现所有的承诺。这也是一种无法持续管理产品待办事项的坏方法。
现在，你需要先做这些事：
- 理解产品战略；
- 清理 / 删掉产品待办列表；
- 定义要验证的假设；
- 创建与战略相关的事项，重建列表。
