原作者： Alexandre Klaser
原文链接： Backlog Gone Wild? You Can Still Tame It
翻译：北十九
在一个功能团队中，如何管理 backlog 是一个很重要的事情，这可以帮助团队保持一个相对稳定的节奏和良好的交付质量。
但是，有时你意识到你的 backlog 仅仅变成了一团乱麻的用户故事板。亡羊补牢为时未晚，让我们一起看一下下面这几种方法，让 backlog 重新步入正轨。
跟着价值走
就如 Deep Throat 在电影《总统班底》中说的：『一切朝钱看』。在软件开发中，我们有一个类似的建议：一定要关注在可以给产品提供商业价值的事情上。
因此，如果有些可以给产品提供价值的点，让我们把它抓住，写成用户故事，放到 backlog 里以后做，如何？好吧，其实不用这么快！
在一维 backlog 中的用户故事，我们都认为它们自己就能独立增长产品的价值，这是 scope 悄悄扩张的一个主要原因，这也是为什么 INVEST 原则从长期会走歪路，并最终导致失败的原因。在你 backlog 中包含进来的任何东西都必须与一个清晰的（并且可计量的）目标相挂钩。
组织 Backlog
在一个最近的项目中，我们刚开始只是通过电梯演讲（Elevator Pitch）和史诗（epic）级别的用户故事，来产生了一个高层次的项目目标。随着项目的推进，团队忘记了 backlog 中那些用户故事到底为了什么。史诗故事只是列出了未来要做的事情，而不是一个计划，要让我们按照它的方向前进。
在那个项目中，做迭代计划变得更加困难，我们很快意识到已经有太多的用户故事要做了，而没有足够的迭代时间来做。
为了解决这些问题，我们计划了一个 backlog 减肥工作坊，分为以下四个简单的步骤：
1. 辨识目标并排优先级
在工作坊的第一个练习中，团队将用户旅程（Uesr Journey）进行映射，来辨识出当用户与应用进行交互时，到底需要完成什么事情，然后我们把这些信息进行分组，作为产品的目标。
基于我们从这个练习中学到的东西，很容易看到为完成每个目标的潜在影响，这帮助我们有根据的排列它们的优先级。
2. 通过目标和用户来进行故事分组
接下来我们创建一个矩阵，我们把目标按优先级排序，依次放到 x 轴上，把用户按照被产品影响的大小，依次放到 y 轴上。
我们把 backlog 中的故事挨个过了一遍，辨识出存在于矩阵中的会被影响的用户，并把故事和目标建立关联。
在完成了这个练习后，我们得到了一个对我们想要完成的事情的清晰的画面，这些事情为谁而做，以及为什么。我们可以把与最低优先级目标挂钩的这些故事去掉，因为这些目标并不是产品成功的关键因素。
我们必须要决策的第二个点是，我们怎样影响我们的用户。我们可以把工作分成垂直的块（试着一次去满足多个用户的同一个目标），或者水平的块（试着去给某个用户他/她需要的多个功能，来满足跟他有关的多个目标）。
因为这个产品是跟工作流有关的，故而使用一次仅关注一个目标，对与这个目标相关的全部用户，提供他们完成部分工作所需的全部功能，这种方式比较好。
这些故事使用『作为...我想要...以至于』 的形式，但是大量集中在『以至于』的部分目标都太细粒度了，以至于我们花了一些工夫，才把它们跟我们在矩阵中使用的高层次的目标关联起来。在这次工作坊之后，我们再创建故事就开始使用『为了...作为...我想要』的形式了，因为这样更容易从高层次来认识用户故事。
3. 挑重要的做
但这还不够。跟我们离场时所能做完的相比，Backlog 里的故事还是太多了。
因此我们需要把剩下的故事分成3个等级：基本需求，可协商的需求和不确定的需求。
在基本需求等级中，我们把已经被实现的这些功能归为一组，来确保工作流基本的机制已经被满足了。这些都是一个个足够小的实验，很快就可以用来验证我们距离目标到底有多近。
在不确定的需求等级中，我们把那些在某种意义上明显属于『nice-to-have』的故事归为一组，这些故事并不一定能够满足用户的目标。这些故事用来覆盖可能的改进点（或者边界情况），我们仍然需要多研究一下来决定他们的真实价值。
4. 对可协商的故事，关注在最有价值的那部分
那时我们可以肯定两件事情：我们必须实现的故事和我们可以从 scope 中移除的部分。
在中间的等级中（可协商的需求），我们把剩下的卡片都归为这一组。对每个在里面的故事，我们会问下面的问题：
从目标方面考虑，这个故事有多少价值？
我们能把基本的机制隔离到其它的故事中吗（把最基本的功能从它里面抽离出去，把剩下的部分留作『nice-to-have』的卡片）？
通过问这些问题，一部分工作被合理剥离到更高的层次去，我们现在不需要去关心他们。对于剩下的那些最有价值的部分，就被移到了基本需求等级中。
下一步怎么做？现在轮到你了！
通过这些简单的步骤，我们抽离出了原来 backlog 中更小的子集来做后续开发，在确保我们达到最重要目标的这个过程中，更快的试验和学习。
与构建在 backlog 中说明的所有东西相比，我们关注在那些可以帮助我们验证假设的用户故事，这样来在最短的时间里增加价值。项目中剩下的时间可以用来重新审视（甚至创建全新的）我们值得去做的故事，这样我们就做到了基于目标来驱动开发。
如果你碰巧也遇到同样的情况，为什么不试下这些简单的方法？这些方法可以帮我们很多忙，把你的 backlog 改成面向目标的，着一定也是极好的！
