Agile Product Management Tip: Illustrate the Ticket Backlog

Want to reduce conflicting requests from executives, sales, marketing, business development, and the board for product enhancements? Illustrate the existing backlog of bug reports and committed enhancements so that everyone can see what the company has ALREADY committed to do.

People in each functional role have their own narrow, deep view of reality based on their job responsibilities and the information those responsibilities make them aware of. Engineering is deeply aware of technical debt and the need to refactor the application. Marketing knows the new functionality that’s needed to support their demand generation initiatives. Each account representative is acutely aware of the bugs affecting their current accounts and prospects and the enhancements they think they need to close new business. The CEO may have a grand strategic vision for world domination and know the work needed to get there. Support is aware of the problems they see frequently across numerous accounts.

Product managers are different because they receive all that incoming information and get a unified view of needs across the organization. By default, product managers have a broad, shallow understanding of what needs to be done. They see ALL of the incoming requests, keep them all balanced in their head, and compare them. Each account manager tends to assume that his or her bugs HAVE to get fixed right away and his or her new features HAVE to get implemented soon, but the product manager knows that there are ten account managers who each feel that way about their own favorite bugs and enhancements and the company can’t do them all in the next six months. People in the other functional roles are like submarine commanders looking out at the world through periscopes; the product manager is standing on the deck of an aircraft carrier and seeing the whole ocean at once.

A related problem is that when the product manager and another person have a conversation and agree in principle that a particular problem must be solved or feature must be added, the other person will tend to walk away mentally considering the problem “solved” before work on it has even begun. The product manager has agreed in principle that the work must get done “at some point,” so the other person will mentally tick that issue off their list and start focusing on other issues. The problem is that at that moment, the amount of work that must get done is likely not fully understood and will only become fully apparent after the bug is investigated or the user stories are written for the feature. The product manager has to start work on figuring out a plan for actually getting the work done. Meanwhile, the other person has forgotten about the first issue and will start lobbying for commitments to address another one, then will wonder much later why the first issue isn’t already resolved.

This difference of perspective and perception will lead to conflict between product management and people in other roles if you don’t manage it carefully. If the product manager doesn’t communicate the existing global workload back to people in each functional role in a readily understandable way, they will wonder why product management is “aloof” and “not responding” to their urgent, important local requests. To extend the metaphor, the submarine commanders may start firing torpedoes at the aircraft carrier if they don’t understand that it’s spread thin responding to EVERY submarine commander’s requests for assistance, not just their own.

Illustrating the backlog of existing committed and necessary work in ways others can easily understand is a great way to reduce conflict between product management and other functional roles and (better yet!) to make people stop and think before they push really hard for the latest bright idea of the last five minutes.

To illustrate the backlog of existing committed and necessary work, first you have to know what it is. It’s not enough to say that “There are 1800 tickets of all kinds in our ticket tracking system, so we can’t do any new work for the next six months.” That statement is not credible because everyone knows that not all tickets have to be addressed at all, let alone within the next six months. If your ticket tracking system isn’t already well organized, you must first define multiple backlogs. At a minimum, you need a “current” backlog for agreed-upon short-term work and a “future” backlog for work you’ve decided doesn’t need to be done in the short term. You may want a separate backlog for each major upcoming release such as private beta, public beta, 1.0, and so on. You need to have a clear definition of what the company is already currently committed to do. This means you either must have a rational road map commitment process already in place or you need to catch up by doing a quick list of the major work items you think everyone agrees must be done and then doublecheck with the executive team to verify that they really do agree. Then you have to do a bug scrub and make sure your tickets are prioritized, tagged, and assigned to the appropriate backlogs. You also need to know what your velocity per sprint is, either in raw tickets per sprint (if that’s all you’re tracking) or better yet in work units per sprint such as story points.

Now you’re ready to illustrate and communicate the backlog in ways others will understand. The details of exactly how you express the problem will vary depending on the units you use for tracking (raw tickets? story points? ideal days? person hours?) and how you include bug fixes in measurements of work accomplished. (Do you only count user story points towards velocity? Fine, but then you need some measure of the effort for each bug fix and how much of the team’s capacity that will consume in each sprint going forward.) Here are some of the metrics you should look at as you prepare to give a reality check to everyone else in the company.

• What’s the total number of open tickets on the current backlog and any other backlogs for committed releases? Even if you track work in story points or person hours, this is still a helpful metric because people who don’t understand story points or person hours still can have a loose appreciation for the problem posed by a large number of open, committed tickets.
• What’s the total number of open tickets that have been deferred to the future backlog? You use this number to demonstrate that you aren’t mindlessly assuming that every open ticket has to be fixed right away and to show that you’ve actually intelligently triaged work and deferred as much as you can. “Keep in mind, we’re only talking about committed, upcoming work in the short term. This excludes the 560 tickets we’ve deferred to the future …”
• How much work are you currently accomplishing per sprint? To illustrate how long it will take to complete the existing committed work including both new features and bug fixes, you need to measure the total work you’re accomplishing per sprint on both features and bug fixes. If you’re using story points, ideal days, or person hours to measure both user stories and bug fixes, that’s easy. If you’re using one metric for user stories and another for bug fixes, it’s harder.
• How long would it take us to resolve the existing backlog(s) of committed work if we did only that work and did no other new features and assumed there were no other new bug reports or escalations hereafter? This is obviously not how long it will actually take (there will probably be some new features you have to add or new bugs you have to fix), but it starts resetting people’s expectations to a more realistic level. You start by saying something like “Even if we agreed to do no additional features or bug fixes besides those already committed, it would take us six full months to close out the existing backlog of committed work.” At this point, people start to understand because they all realize that they can’t realistically commit not to ask for any new features or bug fixes for six straight months.
• How long will it take us to resolve the existing backlog(s) of committed work if we assume only part of each sprint will go to the existing backlog and a reasonable part will be kept free for requirements we don’t know about yet? Now you figure out how much of the available go-forward capacity you need to mentally reserve for “critical needs we haven’t thought of yet” and “critical bug escalations that haven’t happened yet.” It’s probably reasonable to assume that between 25% and 33% of each sprint will be consumed by things you haven’t thought of yet. Then you see how long it will take to resolve the backlog using this more realistic estimate of how much capacity you can currently commit from each upcoming sprint.

After you’ve gathered all this data, you want to run through these points privately with your peers in engineering, support, QA, and sales management and the executives in each of those areas before you announce your findings to the whole company at once. First of all, they may spot something you’ve overlooked, so this is a useful check on the validity of your findings. Maybe one of those “commitments” isn’t so important and it can be deferred given the improved understanding of the current backlog. Even if the situation can’t be improved, you need to let people down gently in private and give them a bit of time to adjust their expectations. If a company hasn’t done this kind of exercise at all or in a long time, people tend to have unrealistic expectations. You need to gently deflate unrealistic expectations in private before doing it all at once for the whole company in a surprise email blast.

Once you’ve talked with people privately, do make sure by some means that everyone in the company understands the broad outlines of your findings. It will make all future conversations about requests for enhancements and bug fixes easier because you’ll be able to refer to the size of the existing backlog when you start explaining why a particular bug report or feature request can’t be addressed for quite a while to come. You’ll be able to say “I agree with you that this is something that we’d like to do. But the problem is that we already have six months of more urgent and important work already committed on the backlog, so we’ll have to defer this to the future and re-evaluate it later.”

Getting the rest of the company to understand the size of the current backlog of committed work isn’t a panacea. But it’s a necessary first step towards getting people’s expectations set at a reasonable level and reducing the level of frustration, unhappiness, and drama in conversations about new feature requests going forward.