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.

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.

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.

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.

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.

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.

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.

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.

There can be fully fleshed out features…

…tiny bug fixes, optionally including subtasks…

…or they can be fanciful one-line aspirations fleshed out with potential subtasks and sub-subtasks, even ones that might not be technically possible.

Sometimes it’s very clear what the acceptance criteria might be, although usually those acceptance criteria need to be fleshed out in conversation with the team. Quire is unopinionated about where you create these, but the logical place is in the description field for the task.

Product backlog tasks also may be driven by very specific technical requirements, user experience testing, and other documentation that needs to be associated with them, so is convenient if you’re using a tool like Quire that allows you to attach other documents to an individual task. It even has Google Drive integration.

Who Needs to See the Product Backlog?

Quire tasks can be kept in the product backlog at all stages of planning, but by the time they’re presented to the team they should be ready for a complete discussion. I like to think of the product backlog as a magic bag of secrets a product owner controls. Over time, and with appropriate fanfare, the product owner can reveal plans to the team and engage them with the value that these new features promise to the end user.

Which is not to say that the team must be kept in the dark about where the product is headed. The reason a product owner sits with the development team is so that there can be a constant back and forth dialogue as features are developed and as plans for future features are being created. But one of the benefits of working in an agile way is that the team can productively focus on stories as they are defined and groomed without worrying that they will be interrupted by scope creep from shifting requirements after the work has started.

So feedback should be sought from the developers as needed to make sure a potential feature is possible, but the discussion needs to be handled carefully, so the team doesn’t misinterpret a potential new feature or enhancement as a mandatory shift to the work currently in progress.

Tools like Quire, that sit outside of the traditional agile storyboard tools, are very useful for maintaining the privacy of a product backlog. There’s no need for setting special permissions on descriptions of features that may never be worked on so the team doesn’t get distracted. That allows a product owner to avoid contaminating the work in progress with possible changes coming down the road. Since the product backlog is being managed with a separate tool, only the product owner needs to have direct access.

How Do You Keep the Product Backlog in Sync with the Team?

The final challenge for a product backlog solution is how well it can stay in sync with the work the team is doing. One of the main advantages of using a shared tool that everyone on the team can see is that any changes are immediately reflected to everyone using the same board. But that usually comes at the cost of being able to keep potential future features private until it’s time for the team to start grooming real stories.

If the product owner tries to maintain the backlog using a non-agile tool, such as a spreadsheet or a word processor, the difficulty is doubled. Not only does it require manually synchronizing the backlog with the work the team is doing, it also means developing a system of coding the ideas so that it’s clear what state they are in. For example, how would a product owner distinguish in a word processor backlog among features that are in progress, that may never happen, or that are fully developed and deployed?

An agile-friendly notebook is what’s needed, and Quire serves that purpose admirably. The default Quire interface includes just enough detail to create and track the progress of tasks as they get fleshed out without getting in the way of the creative process for the product owner. But Quire also provides a customizable Kanban board view that product owner can use to track the status of tasks after they have been groomed and transferred to other systems as fully estimated stories, without interfering with the rest of the team.

By configuring the Kanban board view to match the states the team is using, a product owner has the option of adding Quire tasks to the board and tracking their progress through development and deployment as the team moves forward. It’s as easy as clicking the Board icon in the task detail view…

…and selecting the configured Kanban board, and then switching to the Kanban view to drag tasks around.

If used this way, Quire can also generate reports on the status of stories in development with integrated tools, using attractive and executive-friendly charts and graphs. These can be referenced in discussions with executives and stakeholders or shared with the team as the product owner sees fit.

If the team finds them useful, they’re available, but the product owner may decide that some charts, such as Quire’s Gantt chart view of potential planned work, don’t add value or may actually be a distraction to an agile team.

Creating and maintaining a product backlog is an essential part of the role of the product owner. The product owner needs to maintain a backlog to facilitate creating and tracking the priority of potential stories for the team to work on. Because of its native integration of Kanban features in a task-oriented interface, and its convenient nested subtask interface, Quire may be a better solution than trying to use the same board the team uses for active stories, or cobbling together a custom solution with spreadsheets and word processors.