经验分享:删掉 500 个产品待办事项后,我逃离了「假敏捷」
文章开始之前,我想先请大家思考几个问题: 你的产品待办列表中有多少项工作? 其中最早的待办事项是什么时候创建的? 你和 Scrum 团队多久会维护一次列表中那些从没进过迭代的「钉子户」事项? 我第一次问自己时,得到的答案是这样的: 产品待办列表中有 450 个待办事项; 最早的一项在三年零七个月前创建; 至少有 100 个事项被完善和评估,却从未被规划进迭代。 我开始反思产品待办列表(Product Backlog)和产品待办事项(Product Backlog Item)的奇怪现象,随后确定了一件事情:我没有理解「敏捷」的真正含义。 现在我将与你分享,为什么清理(甚至删除)产品待办列表可能让你拥抱更自由的敏捷。 01 笨重的产品待办列表是敏捷的劲敌 你能立刻说出「敏捷」的含义吗? 一千个人眼中有一千个哈姆雷特,而我的理解是:敏捷要更快地向用户和业务提供价值。 对于抽象的「价值」,大家或许也会有不同的解读。于我而言,「提供价值」意味着在帮助用户解决问题的同时,为业务带来回报。 从容地面对未知是践行敏捷的关键。 追本溯源,敏捷强调拥抱变化,在变化中学习。我们应该简单地创建假设、验证假设、...