对于敏捷积压工作,没有明确的规则手册——每个团队的积压工作结构可能不同。在其核心,这是一个好的事情:每个团队都有自己的工作方式,所以一个尺寸适合所有过程并不实用。但是,由于这种灵活性和缺乏官方规则,UX有时会遗漏过程。

定义:A.积压是一个有序的待办事项列表 - 包括功能,对现有功能的更新,错误修复,用户体验债务,或团队为完成项目而打算开展的其他活动。

敏捷中的积压

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

优先级是任何敏捷团队的一项重要任务,因为它决定了在给定的sprint中将完成哪些用户故事。根据您的利益相关者对用户体验价值的信任程度,代表用户体验工作的用户故事可以被去优先级化,以支持以开发为中心的用户故事。

待办事项列表结构

敏捷团队经常面临一个困境:他们应该使用一个包含用户体验工作的待办事项,还是使用一个独立于开发用户情景的专用用户体验待办事项?

两种方法 - 遵循一个统一的积压或维护多个积压 - 可以成功,具体取决于它们的实施方式。关键是要了解您的团队如何共同运作以及您的利益相关者对积压的影响程度。让我们来看看这些不同的积压模型的一些优点和缺点。

统一的积压:同一积压中的显式UX和开发项目

统一的backlog存储产品的所有工作,包括开发任务、UX活动和QA任务。

优先事项

标题

用户故事

故事点

标签

1.

在仪表板上导出数据

作为仓库经理,我想从我的仪表板导出数据,以便我可以运行夜间报告。

5.

特色

2.

原型:过滤增强

作为仓库经理,我想过滤我的数据。

2.

用户体验

3.

重置密码

作为系统用户,我想为我的帐户输入新密码。

2.

特色

4.

新的潜在客户警报

作为客户经理,我想知道潜在的新客户端请求信息。

3.

特色

统一待办事项列表中的sprint示例:项目可以与用户体验相关,也可以与开发相关

在这个待定项示例中,sprint由4个待定项组成,每个待定项都有相应的内容故事点估计. 突出显示的项目,原型:过滤增强,是指构建和测试原型的UX特定项目。

吉拉积压
JIRA软件:Backlog项目可以标记为UX,以帮助团队区分多种类型的工作。

由于统一积压工作中包含明确的特定于用户体验的项目,用户体验工作与积压工作中的任何其他工作一样,都会得到优先排序和评估。使用标记、特定任务名称(例如,以字符串为前缀)区分UX积压项目和开发项目用户体验),或使用产品管理软件中的专用功能(例如标签或类别)。

赞成的意见

此方法使团队及其利益相关者可以看到UX工作。每个人都可以看看积压,知道需要做些什么。使用产品管理软件中的标签将使UX项目易于过滤。

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

欺骗

用户体验项目可以由利益相关者取消优先级,以支持新功能-尤其是如果他们看不到用户体验研究的价值。如果您发现您的利益相关者一直在对与用户体验相关的积压工作项目进行非优先级处理,那么您需要尝试本文后面介绍的另外两种积压工作技术中的一种。

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

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

组织待办事项的第二种方法是将每个待办事项分解为一组不同团队能力的子任务(例如,用户体验任务、开发任务)。

优先事项

标题

用户故事

故事点

标签

2.

过滤增强功能

作为仓库经理,我想过滤我的数据。

2.

增强

任务

分配给

设计过滤视图

用户体验

结合用户反馈

用户体验

实现过滤视图

发展

回归试验

质量保证

一个统一待办事项的示例,其中每个项目被拆分为分配给不同角色的多个组件

在本例中,backlog项过滤增强功能分解为4个子任务-一些用于用户体验,一些用于开发,一些用于质量测试。当所有这些子任务都完成时,待办事项即被视为完成。

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

赞成的意见

当设计和开发可以在一次冲刺中完成时,这种方法最有效。当团队正在使用良好的域名和小型或集中的设计问题时,这通常是这种情况。由于团队的所有成员都在完成工作的同时,团队需要确保UX的工作不会阻止团队的其余部分取得进展。

很容易看到每个待办事项的清单。团队中的每个角色都在积压项目上有相关的任务;因此,不同类型的工作的依赖性将更容易地识别,而不是与混合项目统一的积压。更好地跟踪尚未完成的内容也是可能的。

欺骗

团队需要熟练估计待办事项。由于您将有多个角色处理同一积压工作项,因此估计可能会变得混乱。一些团队喜欢在开发项目中使用规划扑克或斐波那契序列,而在用户体验工作中使用t恤尺寸。

用T恤尺寸估算
在估算t恤尺寸时,小的项目可以快速完成,无需进行大量测试,而大的项目需要更多时间,可能是冲刺中完成的唯一项目。

根据任务的进度,您有可能将积压项目从一个sprint转移到另一个sprint。例如,如果合并用户反馈是一项直到冲刺结束才发生的用户体验任务,那么相应的开发任务可能会滚动到下一个冲刺中,这也会将整个待办事项也进行下去。

多个积压

最后一个待办事项模型是维护多个待办事项,每个能力对应一个待办事项-例如,一个UX待办事项和一个主开发待办事项。通常,只有在您尝试了其他两种模式之后,我才推荐此模式,因为维护多个积压需要大量的规程和沟通。这种方法也适用于Siled UX团队或团队,具有多个UX专业.

UX Backlog.

原型:过滤增强

可用性测试:过滤增强

UI设计:过滤增强功能

设计冲刺:新的客户端警报

设计Sprint:仪表板导出

仅列出了仅列出了UX相关任务的UX积压的示例

在本例中,产品待办事项和UX待办事项是独立的。UX积压工作由基于产品积压工作中的积压工作项创建的UX相关任务组成。

仍然会有一个主要的产品待办事项清单,其中包含您的所有新特性、反馈、bug等等。单独的用户体验积压工作将包括所有不同的用户体验活动。这将取决于您和您的产品负责人,以确保您在正确的时间从事正确的工作。有时候,UX可能需要在团队其他成员之前就完成一项任务,以便开发能够以合理的解决方案进行。回到上面的例子,如果你看到新客户端警报在Sprint 3中的产品积压上,您需要确保完成设计冲刺:新的客户端警报早在开发开始之前。

赞成的意见

UX完全负责自己的积压工作。UX团队正在决定需要完成的工作以及何时,可以计划上市的积压项目。此外,由于UX在开发之前工作,因此在冲刺中持有开发人员的风险越来越少。

单独的用户体验积压可以扩展到多个工程团队和用户体验专业。如果您的组织拥有一个具有多种专业的大型UX团队,每个人都可以讨论与她的专业相关的任务。此外,如果您的组织有多个工程团队在同一产品上工作 - IOS,Android和Web团队,例如 - 所有UX任务都可以居住在一个积压中,以帮助保持所有团队的一致性。

欺骗

难以衡量整体团队速度。由于UX从单独的积压工作,因此其速度与开发团队的速度不相结合。(某些团队不会认为UX作为其团队速度的一部分,因此这方面可能不是一个配置。)

工作太超前有风险。当您提前计划产品待办事项时,我们建议您将大部分精力集中在当前和下一个sprint中的事项上。如果您的团队在除初始研究之外的任何其他方面都在进一步工作,那么在项目被取消优先级的情况下,就有很大的工作损失风险。

结论

您的积压结构可能会从团队转到团队和项目到项目。积压的伟大事物就是你能够和必需的是灵活的。不要害怕混合和匹配不同的方法,直到你找到适合你的团队的方法。