当达到敏捷的积压时,没有明确的规则本 - 每个团队都可以以不同的方式构建其积压。在它的核心,这是一个thing: every team has its own way of working so a one-size-fits-all process isn’t practical. However, because of this flexibility and lack of official rules, UX is sometimes left out of the process.

定义:一种积压is an ordered list of to-do items — including features, updates to existing features, bug fixes,ux债务或其他活动 - 团队打算提供完成项目。

敏捷的积压

在大多数敏捷团队中,功能规划以形式记录user stories。每个用户故事都是给予验收标准的验收标准和估计努力,以完成它们,然后根据利益相关者,业务和开发团队的需求进行故事列表。

优先级排序是任何敏捷团队的重要任务,因为它决定了在给定的Sprint中将完成的用户故事。根据您的利益攸关方认为UX的价值,代表UX工作的用户故事可以剥夺以开发的用户故事而抵御。

积压结构

敏捷团队往往面临困境:他们是否应该使用一个包含UX工作的积压或使用与开发用户故事分开的专用UX Backlog?

Both methods — following one unified backlog or maintaining multiple backlogs — can be successful, depending on the nuances of how they are implemented. The key is to understand how your team works together and how much influence your stakeholders have on the backlog. Let’s look at some pros and cons of these different backlog models.

Unified Backlog: Explicit UX and Development Items in the Same Backlog

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

优先

Title

用户故事

Story Points

标签

1

在仪表板上导出数据

一种s a warehouse manager, I want to export data from my dashboard so I can run nightly reports.

5.

特征

2

原型:过滤增强功能

一种s a warehouse manager, I want to filter my data.

2

ux.

3.

重设密码

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

2

特征

4.

新的潜在客户提醒

一种s an account manager, I want to know when potential new clients request information.

3.

特征

统一积压中的Sprint示例:物品可以是UX相关或开发相关的

在此后台示例中,Sprint由4个积压项组成,每个项目都具有相应的故事点估计。突出显示的物品,原型:过滤增强功能,是一个特定于UX的项目,指的是构建和测试原型。

Jira Backlog.
Jira Software: A backlog item can be labeled UX to help the team differentiate multiple types of work.

使用统一积压中包含的显式UX特定项目,UX工作是优先考虑的,并且在积压中的其他任何其他内容估计。使用标签,特定的任务名称(例如,字符串前缀,将UX Backlog项目从开发项目中区分开ux.)或通过产品管理软件中使用专用功能(例如,标签或类别)。

凡好

此方法使UX工作与团队和其利益相关者可见。Everybody can look at the backlog and know what UX work needs to be done. Using tags in your product-management software will make UX items easy to filter.

ux.-related backlog items are often large, general tasks rather than small, specific ones- 试图设想整个工作流程或互动的设计师,而不是一小块的设计师。敏捷积压中的用户故事通常是特定的,并设置为在单个Sprint中完成。但是,我们经常需要在更高的级别上考虑UX工作,以确保我们在整个应用程序中保持一致性,我们的设计适应较大的应用愿景。使用显式UX特定的Backlog项目不会限制UX工作的范围。

cons

UX物品可以通过利益相关者剥夺以支持新功能 -特别是如果他们没有看到UX研究中的价值。如果您发现您的利益相关者始终如一地使ux相关的积压项目,您将想要尝试本文后面解释的其他两个积压技术中的一个。

跟踪依赖关系可能更难。某些UX特定项目可能会影响其他积压项目,这意味着您需要确定需要先完成的内容。如果在您的产品管理软件中使用标签或类别,则可能很容易离开此功能。但是,请仔细注意依赖关系,以避免在您可以进行充足的UX工作之前在积压项目上工作。

基于任务的统一积压:基于角色的工作表达为Backlog项目中的任务

组织缓冲区的第二种方法是将每个项目分解为不同的团队能力(例如,UX任务,开发任务)的一组子特派团。

优先

Title

用户故事

Story Points

标签

2

Filtering enhancements

一种s a warehouse manager, I want to filter my data.

2

加强

任务

一种ssigned To

Design filtering views

ux.

合并用户反馈

ux.

Implement filtering views

Development

回归测试

Quality Assurance

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

在此示例中,Backlog项目Filtering enhancements分解为4个子任务 - 一些用于UX,一些用于开发,以及一些用于质量测试。当所有这些子任务完成后,将考虑积压项目。

在此方法中,UX任务被添加到需要的任何积压项目中UX工作。UX任务的示例包括研究,设计和可用性测试。

凡好

这种方法在单个Sprint中完成设计和开发时最佳。This is typically the case when teams are working with a well-understood domain and small or focused design problems. Since all members of the team are completing work at the same time, the team needs to ensure that UX work does not prevent the rest of the team from making progress.

很容易查看每个积压项目需要完成的清单。Each role on the team has associated tasks on backlog items; thus, dependencies across different types of work will be easier to identify than with a mixed-item unified backlog. Better tracking of what has yet to be completed will also be possible.

cons

团队需要熟练估计积压项目。由于您在同一台积压项目上工作了多个角色,因此估计可能会令人困惑。一些团队喜欢使用规划扑克或斐波纳契序列进行开发项目,同时使用T恤尺寸为UX工作。

Estimation with t-shirt sizes
在T恤尺寸估算时,较小的物品可以在不需要考试的情况下快速完成,而大型的项目将需要更多时间,并且可能是Sprint中唯一完成的项目。

有机会根据任务的进度,您将携带从Sprint到Sprint的积压项目。例如,如果结合用户反馈是一个不起冲刺末尾不会发生的UX任务,则相应的开发任务可能滚入下一个Sprint,这也将携带整个积压项目。

Multiple Backlogs

最后一个积压模型是维护多个积压,一个用于每个能力 - 例如,UX Backlog和主要开发积压。一般来说,我只才推荐此型号在您尝试过另外两个之后,因为需要大量的纪律和通信来维护多个积压。这种方法也是理想的siloed UX teams or teams with multiple UX specialties

ux.Backlog

原型:过滤增强功能

可用性测试:过滤增强功能

UI设计:过滤增强功能

设计Sprint:新客户端警报

Design sprint: Dashboard export

一种n example of a UX backlog in which only UX-related tasks are listed

在此示例中,产品积压和UX Backlog是独立的。UX Backlog由基于来自产品积压的Backlog项目创建的UX相关任务组成。

仍然将有一个主要的产品积压,所有新功能,反馈,错误等。您单独的UX Backlog将包括您的所有不同的UX活动。它取决于您和您的产品所有者,以确保您在合适的时间在正确的事情上工作。有时,UX可能需要在团队其他部分之前的任务工作,以便开发继续进行声音解决方案。回到上面的例子,如果你看到新客户警报在Sprint 3中的产品积压上,您需要确保完成设计Sprint:新客户端警报在开发开始前。

凡好

UX完全负责自己的积压。The UX team is making decisions of what needs to get done and when, and it can plan for upcoming backlog items. Also, because UX works ahead of development, there will be less risk of holding up developers in a sprint.

单独的UX Backlogs可以使用多个工程团队和UX专业扩展。If your organization has a large UX team with multiple specialties, each person can work on tasks that are relevant to her specialty. In addition, if your organization has multiple engineering teams working on the same product — iOS, Android, and web teams, for example — all of the UX tasks can live in one backlog to help maintain consistency across all teams.

cons

It is difficult to measure the overall team velocity.Since UX works from a separate backlog, its velocity is not combined with that of the development team. (Some teams don’t consider UX as part of their team velocity, so this aspect may not be a con for you.)

前方工作太远的风险。当您计划未来购买产品积压项目时,我们建议将大部分努力关注在当前和下一个冲刺中的物品上。如果您的团队在初始研究以外的任何内容进一步努力,如果在将物品被剥夺化的情况下,存在很大的失去工作。

结论

Your backlog structure may change from team to team and project to project. The great thing about backlogs is that you’re able andrequired是灵活的。不要害怕混合并匹配不同的方法,直到找到为您的团队工作的东西。