“Why did you close all my issue tickets?” The lead tester on one my projects asked me this question recently, partly in jest and partly out of some frustration. In a three-day period I closed 100 open tickets in the system we use to track software bugs, feature enhancements, and development tasks, and the tester wanted to know if he had been wasting his time writing up tickets for our project. Why did I close so many open issues so quickly? Let me provide some context to explain.
We’ve been building out this particular product for almost two years now. We scoped out a product roadmap that included the key feature sets we planned to add – both those required to launch the product and those initial enhancements we knew we wanted to make. From the start we have used an issue tracking system to record and organize all of the diverse work we wanted to do on this product: large features (overarching user stories), sub-features that we planned for specific sprints, research and product discovery tasks, UI and design issues, software bugs, and user issues that required some kind of resolution. In the past two years we have logged over 4200 issue tickets in this system of different types, and two weeks ago the lead developer on our team asked me as the product manager to sort through this list and weed out some of the issues.
If you’ve been reading my blog you know that I view tending the product backlog as a core responsibility of the effective product owner (you can read my thoughts on this here: http://wp.me/p2BePD-2o and here: http://wp.me/p2BePD-1m). But in truth it’s not that simple. In the midst of a busy schedule this important task sometimes gets less attention than it deserves. While we had been using our issue list to fuel our sprints, this set of tickets had become large and diverse enough to be unwieldy, with over 400 open issues – some from over a year ago. So last week I spent half a day on my own and another hour with the lead developer going through the set of open issues trying to pare down and organize them into a more manageable backlog.
Through this process I found three types of issues we could close and fourth type that we could move off of the backlog and into our plans for the current sprint:
- The first set of issues we closed involved things we decided were too low in priority. Especially early on, we wrote up every small item we saw – whether the issue concerned an actual bug (something not working properly) or a ‘nice to have’ change that might make the product incrementally better. But if any of these issues had languished on the backlog for several months with no impact on functionality, no questions from sales about when the issue would be fixed, and no questions from clients about why things behaved the way they did then we determined these items to be too low in priority for us to address. We can always write them up and deal with them in the future if they rise to the surface, but cluttering our current issue list with dozens of these minor issues seemed unnecessary. Some we maybe never should have written up in the first place, but it was clear that for now none of these items were going to be addressed and so they didn’t belong on the backlog any more.
- Second, we closed issues on the list that we had already handled in a different way. Again, there were a number of issues on this list that referenced the look and feel of the product or the specific behavior of certain screens in the application that have been redesigned since the issues were first written up. At the time these aspects of the product needed attention, but now the underlying problem had been addressed with either a new design or a changed feature. Really we should have closed these issues at the time we decided to shift our product design, but they lingered on the backlog until I took the time to review and close them.
- We closed a third set of open tickets because upon review we discovered that they were really duplicate issues. We have frequent UAT (user acceptance test) sessions and active testers who produce many new issues each sprint. When certain items do not get addressed quickly they can sometimes be written up as bugs more than once. This can also happen when different people are testing the same area of functionality and each one identifies slightly different but related problems. While reviewing our backlog I found a number of these duplicate issues, where more than one ticket really concerned the same problem. Here again I should have closed these duplicates earlier, but once I found them I wanted to close them – better late than never.
- Finally, we found about forty issues which the lead developer and I determined were ‘quick hits’ that we could address in the next couple of sprints. In fact we decided together to allocate a percentage of time in each of the next few sprints to handle these small (largely UI-related) fixes that will both trim our backlog and make sure we fix small user interface items almost as soon as we find them. We still need to make sure these types of issues don’t fall in the first bucket of items I mentioned above, but if we start addressing these small items quickly and handle some of them every sprint we can keep our product backlog much more manageable.
The four hours or so I devoted to cleaning up our issues list (or grooming the backlog in Agile speak) was definitely time well spent – both because it made our backlog a more useful repository for identified issues and because it helped make sure that the lead developer and I are on the same page with what constitutes higher priority items for us to address. We have a feature-rich product that has been evolving for two years now and so it is important to refocus our priorities on a regular basis.
It was also important for me to talk this through with our lead tester, whose frustrated question started my thinking for this blog post. Our testing team adds incredible value in our software development – through the automated testing suites that they create and run, through the regular UAT sessions that they run, and through their diligent testing of every new feature and fix. I try to work closely with the whole testing team and want to make sure that they continue to let me know about every issue they find in our product. Just because some issues we choose not to fix and others become irrelevant as the product plans evolve does not mean that their vital role on our team is any less important. Talking this through helped make sure that our lead tester and I are also on the same page about what kinds of issues to write up and what the central priorities are as we continue enhancing our product.
I know that even as I recommit to staying on top of our product backlog there will come a time in a few months when I will again need to weed out some accumulated items on this list. We cannot effectively plan our sprints if the backlog becomes too large, and I cannot personally find and document every issue on the site. Hopefully the lead tester, lead developer, and I can all keep focused on the top priorities even as we listen to our clients to tell us what gives them the most trouble. Balancing all of this in the midst of our active development cycles is a real challenge because in truth it’s not that simple.