This article was created in partnership with Quire. Thank you for supporting the partners who make SitePoint possible.

本文是与Quire合作创建的。 感谢您支持使SitePoint成为可能的合作伙伴。

The product backlog is probably one of the most controversial and misunderstood artifacts of an agile organization. Everybody seems to have an opinion about what should be on it, how it should be organized, and who should manage it. As a result, creating and managing product backlogs has become more of a dark art than a science. Tools that are optimized for running an agile team sometimes don’t work well for a product owner trying to keep track of stories that the team hasn’t started working on yet.

产品积压可能是敏捷组织中最具争议和误解的工件之一。 似乎每个人都对应包含的内容，应如何组织以及应由谁进行管理有意见。 结果，创建和管理产品积压已不再是一门科学，而是一门黑手艺。 对于负责跟踪团队尚未开始工作的故事的产品负责人而言，为运行敏捷团队而优化的工具有时效果不佳。

One option product owners might want to consider is Quire, an online project management software tool with task and subtask tracking as well as Kanban board features, that can keep pace with an agile team while remaining unopinionated about how a product owner crafts upcoming features and product enhancements. The folks at Quire reached out to me to take a look at their product, and they may have come up with a solution that would work for product owners creating and maintaining a backlog for their teams.

产品所有者可能要考虑的一个选择是Quire ，它是一种具有任务和子任务跟踪以及看板功能的在线项目管理软件工具，可以与敏捷团队保持同步，同时对产品所有者如何设计即将发布的功能和产品保持不受质疑。增强功能。 Quire的人们与我联系来查看他们的产品，他们可能想出了一个解决方案，该解决方案适用于产品所有者创建和维护其团队的积压工作。

什么是产品积压，您如何管理？ (What is a Product Backlog, and How Do You Manage One?)

A product backlog is a collection of potential stories describing features a team may work on eventually that each add value for the customer. In scrum and Kanban, stories are discrete vertically sliced chunks of end-user functionality that are independent, negotiable, valuable, estimable, small, and testable.

产品积压订单是潜在故事的集合，这些故事描述了团队最终可以为客户增加价值的功能。 在Scrum和看板中，故事是最终用户功能的垂直分割的离散块，这些块是独立的，可协商的，有价值的，可估计的，较小的和可测试的 。

That’s quite different from a waterfall organization, where each chunk of work may be a thoroughly thought out task in a much larger plan that should eventually add value for a customer. Gantt chart tasks are usually presented as sequential and interdependent building blocks from a product requirements document represented by a detailed Gantt chart or something similar.

这与瀑布式组织完全不同，瀑布式组织中的每一项工作都是一项更大计划中经过深思熟虑的任务，最终将为客户增加价值。 甘特图任务通常以详细的甘特图或类似形式表示的产品需求文档中的顺序和相互依存的构建块表示。

An agile team doesn’t default to Gantt charts or detailed up-front plans. Before the team sits down to groom it with the product owner, an agile story is usually much less detailed than a typical Gantt chart task, driven by customer objectives that add value, and with acceptance criteria written in readable Gherkin syntax for clarity. An ungroomed potential story should create an opportunity discussion with the rest of the team about what should be developed and how.

敏捷团队不会默认使用甘特图或详细的前期计划。 在团队坐下来与产品负责人进行梳理之前，敏捷的故事通常比典型的甘特图任务要详细得多，这要归功于客户目标的增值作用，以及以清晰的Gherkin语法编写的验收标准。 一个未整理的潜在故事应该与团队的其他成员就如何发展以及如何发展进行一次机会讨论。

As a result, the changes in the product backlog can look however the product owner wants them to look in order to stimulate that discussion. And this makes it challenging to find a consistent way to manage and store ungroomed stories so they can be tracked and organized in the context of an active development team.

结果，可以查看产品积压中的更改，但是产品所有者希望他们查看以激发讨论。 因此，要找到一种一致的方式来管理和存储未整理的故事，以便在活跃的开发团队的情况下对其进行跟踪和组织，将是一项挑战。

产品待办事项应存储在哪里？ (Where Should the Product Backlog Be Stored?)

Unlike many agile artifacts, which thrive in the light of transparency, the product backlog actually benefits from a little bit of secrecy. This is a place where the product owner can fantasize about what the user might want, and keep track of external requirements as well as experiments that are underway during user experience testing. Only once a feature has been groomed and the team start development do these potential stories need to be converted to a format that can be shared with the rest of the team.

不像许多敏捷工件(这些工件因透明性而蓬勃发展)那样，积压的产品实际上受益于一些保密性。 在这里，产品所有者可以幻想用户可能想要的东西，并跟踪外部需求以及用户体验测试期间正在进行的实验。 仅在对功能进行了修饰并且团队开始开发之后，才需要将这些潜在的故事转换为可以与团队其他成员共享的格式。

讯享网

And that’s the hard part. Often a product owner will default to developing their upcoming features in the same tool that will be used for sharing and tracking them as stories, such as JIRA Agile. Most of these tools expect their stories to be populated with estimates, epics, dependencies, owners, etc.

这就是困难的部分。 通常，产品所有者会默认使用同一工具开发即将发布的功能，该工具将用于将其作为故事进行共享和跟踪，例如JIRA Agile。 这些工具大多数都希望他们的故事充满估计，史诗，依赖性，所有者等。

Full-featured agile tracking tools often need to be configured by a scrum master or someone else in the organization to meet agreed standards that limit how stories can be written and edited. Those settings may not give a product owner the option to keep potential stories private before they are ready to share with the team unless the stories are written on a separate board and then transferred later to the team board. That’s a lot more complexity than a product owner needs to think about at the early product backlog stage.

功能齐全的敏捷跟踪工具通常需要Scrum管理员或组织中的其他人来配置，以达到商定的标准，这些标准限制了故事的编写和编辑方式。 这些设置可能不会给产品所有者提供选择，让他们可以与团队共享之前将潜在故事保密，除非将故事写在单独的板上，然后再转移到团队板上。 这比产品所有者在早期产品积压阶段需要考虑的复杂性高得多。

Some product owners just write up their plans in word processor, copying and pasting the text into the appropriate tool when necessary. While this has the advantages of being a familiar and convenient writing environment, it’s difficult to keep track of multiple developing features with various levels of detail. Word processors also don’t provide an easy way to keep track of what stories the team is actually working on are while you’re developing new functionality.

一些产品所有者只是在文字处理器中编写他们的计划，并在必要时将文本复制并粘贴到适当的工具中。 尽管这样做具有成为熟悉且方便的书写环境的优点，但是很难跟踪具有各种细节级别的多个开发功能。 在开发新功能时，文字处理器也无法提供一种轻松的方式来跟踪团队实际正在处理的故事。

Spreadsheets can make it easier to keep track of relationships and associations, but they also tempt a product owner to go deeper into the weeds of a more waterfall process, thinking about stories as sequential elements rather than individual independent features with their own value. Spreadsheets also don’t support a very convenient editing environment for writing and manipulating stories.

电子表格可以使跟踪关系和关联更容易，但是它们也诱使产品所有者更深入地了解更多瀑布过程，将故事视为顺序元素，而不是具有自己价值的独立要素。 电子表格也不支持用于编写和操作故事的非常方便的编辑环境。

So a best of both worlds solution might be a lightweight and independent agile project tracking system like Quire. Using the task-based interface in Quire, it’s possible to keep a running history of all of the stories the team is working on, and simultaneously develop new ideas to think about how they might fit in and be prioritized once they’re ready for the team to start working on them.

因此，两全其美的解决方案可能是像Quire这样的轻量级且独立的敏捷项目跟踪系统。 使用Quire中基于任务的界面，可以保持团队正在处理的所有故事的运行历史记录，并同时开发新的想法，以考虑它们可能适合并在为准备工作做好准备时得到优先考虑。团队开始研究他们。

产品积压中应包含哪些信息？ (What Information Should Go into a Product Backlog?)

In an agile organization, stories represent possible directions to take the overall product to add value for the customer, not fixed requirements with intermediate deadlines that may or may not be driven by the intrinsic value they deliver. Quire allows the product owner to maintain as deep a list of potential changes and features as they like, in various states of preparedness and with or without documentation, reorganizing and shuffling them as appropriate before presenting them to a team for grooming and development. Quire calls these tasks, which is a useful naming convention since they may or may not become true stories until a team grooms and accepts them and starts working on them.

在敏捷的组织中，故事代表了可能的方向，以使整个产品为客户增加价值，而不是固定的要求，中间期限可能由交付的内在价值驱动，也可能不受驱动。 Quire允许产品所有者在各种准备状态下(无论有无文件记录)，根据需要保留尽可能深的潜在更改和功能列表，在将其提交给团队进行修饰和开发之前，适当地进行重组和改组。 Quire称为这些任务，这是一个有用的命名约定，因为在团队修饰并接受它们并开始进行处理之前，它们可能会或可能不会成为真实的故事。

It’s up to the product owner how much or how little information goes into the product backlog, so having a flexible tool that will get the job done and get out of the way is essential. Each task in Quire needs to capture just enough information that it will convey the vision of the product owner, and stimulate the creativity of the team when it’s presented. Quire even supports tagging and filtering, so tasks can be labeled as in-progress, bug fixes, or whatever makes sense for a particular situation.

产品积压的多少取决于产品所有者，因此拥有一个灵活的工具来完成工作并避免麻烦是至关重要的。 Quire中的每个任务都需要捕获足够的信息，以传达产品所有者的愿景，并在提出产品时激发团队的创造力。 Quire甚至支持标记和过滤，因此可以将任务标记为进行中，错误修复或在特定情况下有意义的标记。

There can be fully fleshed out features…

可以完全充实功能...