Product owners have the challenging task of ingesting feedback from multiple sources, organizing it into a meaningful format, and communicating out to the product teams. Feedback is a critical part of the product life cycle. We can’t iterate to make our products better without it, as we talked about in our three-part series on collecting feedback a few weeks ago. But what do we do when we get too much feedback? Backlogs quickly become unmanageable. As product owners, if we become less adept at our backlog, we lose hold on the future direction of our product.
Establish a triage process
Once your product has a feedback stream flowing, you’ll need to take action on it. Input should always be coming directly from your customers, using tools like Jira Capture, Jira Issue Collectors, and Jira Mobile Connect–at Atlassian we use Jira to manage user feedback on our products at https://jira.atlassian.com. Not all feedback in the backlog is valuable, however. Set up a simple feedback loop to triage all incoming feedback. You’ll want to understand each piece of feedback and see if it’s:
- Valid and on target for action: “When I click button X, I expect Y to happen, but instead, Z happens.”
- Represented elsewhere: two tickets express the same feedback.
- Not relevant to the product direction: “There should be another button for option X.“
- Not cost effective to implement: “Hitting esc in the browser should save my form text, should I want to re-use it.”
- As designed: the product team made an explicit decision to work this way. Feedback here should be carefully reviewed.
If your product backlog is clogged with inactionable feedback, you’ll have a harder time moving forward. Send the inactionable feedback to a parking lot. We close tickets of this type with the appropriate resolution. Closed issues are not lost! We can target searches of closed issues just like open ones. Tagging an appropriate resolution makes searching closed issues much more efficient. You never want to delete feedback, as you may want to come back to it, thus take the time to ensure you can quickly find it later. Jira’s resolution fields can be customized to add each of the cases above. Epics, components, and labels can track large feature areas for review at a later time.
Tier your backlog
It costs a product owner time for each issue he or she reviews. The Jira team uses a three-tier backlog to denote levels of review for each piece of feedback. If we expand the first “passes review” section above we can see two more levels of fidelity in our backlog.
In the raw feedback stage, the product owner quickly decides whether to keep or pass on a piece of feedback. If the feedback is kept, then it gets moved to the unprioritized state. This means the product owners intend to take action on it at some point, but it’s not in a state where it can be handed off to the product teams. Once the product owner has fleshed out a particular story, it moves from the unprioritized state into the “ready for feature teams” queue. This queue is the tight, ordered backlog that the product teams can quickly pull into future sprints.
What happens when the “ready for feature teams” queue gets low? The product owner only has to pull from the unprioritized queue. They don’t have to look over the entire backlog as there is a higher fidelity set of data ready for review. Rather than review potentially hundreds (or thousands) of issues, the product owner can see a set of a much lower magnitude.
Jira Software, it’s not just for developers
Many development teams use Jira Software to track their work in an agile fashion. Product owners can use it to track their backlogs. The Jira Product Management (PM) team tracks their backlog with Jira Software using a Kanban board. Kanban boards model a flow process so it’s easy to see issues flow from feedback into features. Note, this is a different board than development uses. Think of it as the precursor to the development process.
The Jira roadmap backlog has four major states:
- Not ready yet: Raw feedback
- Unprioritized: Committed to the back log, but not ready for handoff to development
- Ready for feature teams: The feature teams should work on the highest priority items first
- In design (PM and Dev): The feature story is actively being worked on
The PM team then uses swim lanes to group issues by epic so all of the related issues are contextually close to one another on the screen. Swim lanes can be easily collapsed so the PMs can focus on one epic at a time. This helps the PM quickly traverse the backlog.
For more on managing backlogs and why we think it’s the ultimate to-do list, visit our no-nonsense agile tutorial site.
Ready to transform your backlog but not yet using Jira Software? No worries, you can try it out for free!