How to Manage Your Product Backlog with Quire

Share this article

How to Manage Your Product Backlog with Quire

Key Takeaways

  • Quire is a lightweight and independent agile project tracking system that can help manage a product backlog effectively. It allows for the creation and tracking of tasks and subtasks, while also providing a customizable Kanban board view.
  • The product backlog, a collection of potential stories describing features a team may work on, benefits from some secrecy. Quire allows the product owner to keep track of potential changes and features in private until they’re ready to be shared with the team.
  • Quire’s task-based interface allows for the development of new ideas and their prioritization once they’re ready for the team to start working on them. The information that goes into the product backlog can vary depending on the product owner’s preferences.
  • Quire allows the product owner to maintain the privacy of the product backlog, keeping the team focused on current tasks without distraction from potential future features. It also provides the ability to stay in sync with the team’s work and track the status of tasks after they’ve been transferred to other systems as fully estimated stories.

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

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…

Quire feature

…tiny bug fixes, optionally including subtasks…

Quire bug

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

Quire future

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.

Quire acceptance

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.

Quire attachments

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…

Quire add to board

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

Quire kanban view

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.

Quire chart

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.

Frequently Asked Questions about Product Backlog Management with Quire

How does Quire differ from other product backlog management tools?

Quire stands out from other product backlog management tools due to its unique nested task list. This feature allows for the breakdown of large tasks into smaller, manageable subtasks, promoting better organization and productivity. Additionally, Quire offers a simple, clean, and user-friendly interface that makes it easy for teams to navigate and use. It also supports real-time collaboration, allowing team members to work together seamlessly.

Can I use Quire for large projects?

Yes, Quire is designed to handle both small and large projects. Its nested task list feature allows for the breakdown of large projects into smaller, manageable tasks. This makes it easier to track progress and ensure that every aspect of the project is adequately addressed.

How does Quire enhance team collaboration?

Quire enhances team collaboration by providing a platform where team members can work together in real-time. It allows for task assignment, progress tracking, and instant communication among team members. This ensures that everyone is on the same page and working towards the same goal.

Is Quire suitable for remote teams?

Absolutely. Quire is a cloud-based tool, which means it can be accessed from anywhere, at any time. This makes it perfect for remote teams as it allows for seamless collaboration, regardless of the geographical location of team members.

How secure is Quire?

Quire takes the security of its users very seriously. It uses SSL encryption to protect data and also provides regular backups to prevent data loss. Users can also set permissions to control who has access to their projects.

Can I integrate Quire with other tools?

Yes, Quire can be integrated with a variety of other tools such as Slack, GitHub, and Google Calendar. This allows for a more streamlined workflow as you can manage all your tasks and projects from one platform.

Is there a mobile app for Quire?

Yes, Quire has a mobile app available for both iOS and Android devices. This allows for easy access to your projects and tasks, even when you’re on the go.

How does Quire support Agile methodologies?

Quire supports Agile methodologies by providing features such as Kanban boards and Sprint lists. These features allow for better visualization of work, easier prioritization of tasks, and more efficient workflow management.

Can I customize my Quire workspace?

Yes, Quire allows for workspace customization. You can choose from different themes, adjust the layout, and even customize the task fields to suit your specific needs.

Is there a learning curve to using Quire?

While Quire offers a range of features, it is designed to be user-friendly. Its clean and intuitive interface makes it easy to navigate, even for first-time users. However, like any new tool, it may take a little time to familiarize yourself with all its features.

M. David GreenM. David Green
View Author

I've worked as a Web Engineer, Writer, Communications Manager, and Marketing Director at companies such as Apple, Salon.com, StumbleUpon, and Moovweb. My research into the Social Science of Telecommunications at UC Berkeley, and while earning MBA in Organizational Behavior, showed me that the human instinct to network is vital enough to thrive in any medium that allows one person to connect to another.

joelfquiresponsored
Share this article
Read Next
Get the freshest news and resources for developers, designers and digital creators in your inbox each week