将UX工作整合到敏捷Backlog中

当提到敏捷backlog时，并没有明确的规则手册——每个团队可能会以不同的方式构建自己的backlog。它的核心是a好事情:每个团队都有自己的工作方式，所以一刀切的流程是不现实的。然而，由于这种灵活性和官方规则的缺乏，UX有时被排除在流程之外。

定义:一个待办事项列表是待办事项的有序列表——包括特性、对现有特性的更新、bug修复、用户体验的债务，或其他活动—团队打算交付以完成项目的活动。

积压在敏捷

在大多数敏捷团队中，特性规划都是以用户故事．每个用户描述都给出了验收标准和完成它们所需的估计工作，然后根据涉众、业务和开发团队的需求对描述列表进行优先级排序。

优先级是任何敏捷团队的一项重要任务，因为它决定了在给定的sprint中将完成哪些用户故事。取决于涉众对UX价值的信任程度，代表UX工作的用户故事可以被优先考虑，以开发为中心的用户故事更受欢迎。

待办事项列表结构

敏捷团队经常面临两难的境地:他们应该使用一个包含UX工作的backlog，还是使用一个独立于开发用户故事的专用UX backlog ?

这两种方法——遵循一个统一的backlog或维护多个backlog——都可能成功，这取决于它们如何实现的细微差别。关键是要了解您的团队是如何一起工作的，以及涉众对backlog有多大的影响。让我们看看这些不同的backlog模型的优缺点。

统一的待办事项列表:在同一个待办事项列表中显示用户体验和开发项目

统一的待办事项列表存储了产品的所有工作，包括开发任务、UX活动和QA任务。

一个统一待办事项列表中的sprint的例子:项目可以与ux相关或与开发相关

在这个待定项示例中，sprint由4个待定项组成，每个待定项都有相应的内容故事点估计．突出显示的条目,原型:滤波增强，是一个特定于ux的项目，涉及构建和测试原型。

统一的待办事项列表中包含了明确的特定于UX的项目，UX工作就像待办事项列表中的其他工作一样被优先排序和评估。使用标签、特定的任务名称(例如，以字符串作为前缀)将UX待办事项列表与开发项目区分开来用户体验)，或在产品管理软件中使用专用功能(例如标签或类别)。

优点

这种方法使UX工作对团队及其涉众可见。每个人都可以查看待办事项，并知道需要做哪些UX工作。在产品管理软件中使用标签将使用户体验项目更容易过滤。

与ux相关的待办事项通常是大的、一般的任务，而不是小的、具体的任务-这对那些试图设想整个工作流程或交互的设计师来说是一件好事，而不仅仅是一小部分。敏捷backlog中的用户故事通常是特定的，并且设置为在单个sprint中完成。然而，我们经常不得不在更高的层次上考虑UX工作，以确保我们在整个应用程序中保持一致性，并确保我们的设计适应应用程序的更大愿景。使用明确的UX特定的待办事项列表并不会限制UX工作的范围。

缺点

利益相关者可能会优先考虑用户体验项目，以支持新特性尤其是当他们不认为用户体验研究有价值的时候。如果您发现涉众一直在优先考虑ux相关的待定项，那么您将希望尝试本文后面介绍的另外两种待定项技术中的一种。

跟踪依赖关系会更加困难。某些特定于ux的项目可能会影响到其他待定项，这意味着您需要确定首先需要完成什么。如果您在产品管理软件中使用标签或类别，那么很容易做到这一点。但是，要特别注意依赖关系，避免在对待定项进行足够的UX工作之前进行开发工作。

基于任务的统一待定项:表示为待定项中的任务的基于角色的工作

组织待定项的第二种方法是，为不同的团队能力(例如，UX任务，开发任务)，将每项分解为一组子任务。

一个统一的待办事项列表的例子，其中每个项目被分成多个组件，分配给不同的角色

在本例中，待定项滤波增强分解成4个子任务——一些用于用户体验，一些用于开发，还有一些用于质量测试。当所有这些子任务都完成时，待定项就被认为完成了。

在这种方法中，UX任务被添加到任何需要的待办事项中用户体验工作。UX任务的例子包括研究、设计和可用性测试。

优点

当设计和开发可以在一次sprint中完成时，这种方法最有效。当团队处理一个易于理解的领域和小的或集中的设计问题时，这是典型的情况。因为团队的所有成员都在同一时间完成工作，所以团队需要确保UX工作不会妨碍团队的其他成员取得进展。

很容易看到每个待办事项列表上需要做的事情。团队中的每个角色都有与待定项相关的任务;因此，不同类型工作之间的依赖关系将比混合项目的统一待办事项更容易识别。更好地跟踪尚未完成的工作也是可能的。

缺点

团队需要熟练地估计待定项。由于您将有多个角色处理同一个待定项，因此评估可能会令人困惑。有些团队喜欢使用Planning Poker或Fibonacci序列进行开发项目，而使用t恤尺寸进行UX工作。

根据任务的进展情况，你可能会把待办事项从一个sprint转移到另一个sprint。例如，如果整合用户反馈是一个直到sprint结束才会发生的UX任务，那么相应的开发任务可能会转移到下一个sprint，而下一个sprint也会将整个待办事项列表项目转移到其他项目。

多个积压

最后一个待办事项清单模型是维护多个待办事项清单，每个待办事项清单对应一个能力——例如，一个UX待办事项清单和一个主要开发待办事项清单。通常情况下，我只在您尝试过其他两个模型后才推荐这个模型，因为它需要大量的纪律和沟通来维护多个backlog。该方法也适用于竖井式用户体验团队或拥有多种用户体验专长的团队．

一个UX backlog的例子，其中只列出了与UX相关的任务

在本例中，产品待办事项列表和UX待办事项列表是独立的。UX待办事项由与UX相关的任务组成，这些任务是基于产品待办事项列表中的待办事项项创建的。

仍然会有一个包含所有新特性、反馈、bug等的主要产品待办事项列表。你单独的用户体验backlog将包括你所有不同的用户体验活动。这将取决于你和你的产品负责人，确保你在正确的时间做正确的事情。有时候，UX可能需要在团队其他成员之前完成一项任务，以便让开发继续进行一个可靠的解决方案。回到上面的例子，如果你看到新客户警报在sprint 3的产品待办事项列表中，你需要确保你完成了设计冲刺:新客户端提醒在开发开始之前。

优点

UX完全负责它自己的backlog。UX团队正在决定什么时候需要完成，它可以为即将到来的待定项做计划。此外，因为UX工作在开发之前，所以在sprint中阻碍开发人员的风险会更小。

独立的UX backlog可以通过多个工程团队和UX专业人员进行扩展。如果您的组织有一个具有多个专业的大型UX团队，那么每个人都可以从事与她的专业相关的任务。此外，如果你的组织有多个工程团队在同一个产品上工作——例如iOS、Android和web团队——所有的UX任务都可以放在一个backlog中，以帮助保持所有团队的一致性。

缺点

很难衡量整个团队的速度。因为UX工作于一个独立的backlog，所以它的速度不能与开发团队的速度相结合。(有些团队并不认为UX是团队速度的一部分，所以这方面对你来说可能不是一个缺点。)

有太过超前的风险。当您提前规划产品待办事项列表时，我们建议您将大部分精力集中在当前和下一个sprint中的项目上。如果您的团队正在进行除初步研究以外的任何工作，那么在项目被优先考虑的情况下，就有很大的损失工作的风险。

结论

您的待办事项安排结构可能因团队和项目的不同而不同。积压工作的好处是你能要求是灵活的。不要害怕混合和匹配不同的方法，直到你找到适合你的团队的方法。