This is a guest post by Johanna Rothman
It’s common for teams to have large lists of bugs, large backlogs, and large lists of various things to do. Does it make sense to do so? Here are some guidelines for how much to keep around and how you might organize the work.
Paula finished her first month as a new test manager in an organization struggling with their agile transformation. She’d met with all the testers and established regular one-on-ones. She worked with her peers to create communities of practice, so all the people on the teams had a chance to learn every week.
And, she puzzled about what to do with all the bugs and large and extensive backlogs. She felt as if the teams and product owners were hoarding the information, just in case they needed it.
When the organization started to use an agile approach, they hadn’t changed how they managed their list of things to do at some point. They used the same defect tracking system. They used the same road-mapping tool. They used the same project portfolio tool.
The tools weren’t the problem. The way they used the tools created big problems. That’s because as an organization, they planned very far in advance in detail. They never deleted anything. They wanted to make sure they didn’t lose all the good ideas.
It was time to start changing the planning by removing items, not adding more.
Remove to Clarify
In an agile transformation, we often need to remove steps in the process. Teams often use the retrospective to clarify their team’s process and change it.
Many teams and organizations recognize that they need to remove process steps. We don’t often remember to remove some of the data.
Paula discovered that the teams (including the product owners) had to review and re-rank some of the hundreds of bugs in the bug tracking tool. One of the products had just had its tenth anniversary. That product had thousands of supposedly-active bugs in the bug-tracking tool.
Paula suggested this experiment to each team: What if they copied all the bug data to a backup version of the database and started off with no bugs in the current bug-tracking tool? As the team found problems, they could add the problem to the bug-tracking tool. Could they do that?
At first, most of the product owners said, “NO!” The product owners were concerned that the teams wouldn’t fix the discovered problems.
Paula suggested these alternatives:
- As the team re-discovered a known problem, add it to the bug-tracking tool. That would reinforce everyone’s knowledge that they really did have this problem.
- Take the problems still remaining open in the past two to three months, and populate the new bug-tracking tool with those problems. Create a plan to fix the problems.
- Spend not more than an hour selecting the highest impact problems from the current bug-tracking tool and add them to the new, cleaned-up version of the tool.
Paula explained that everyone suffered from cognitive load from having to think about the problems all the time. And, that the product owner had to make difficult choices about what to fix and what to wait to fix.
With fewer items to consider, the team might see their way to fixing problems as the problems appeared. The team wouldn’t wait to fix the problems.
That not-waiting meant the product would improve—maybe slowly at first—over time. But, because the team fixed problems as they saw them, the product would improve.
Each team decided on the possibility that worked for them. And, one of the product owners had this question: “I use the bug-tracking tool as a way to add ideas that don’t go onto the backlog yet. I also use the roadmap. How do I make sure I don’t lose all my good ideas?”
Paula understood that product owner’s dilemma. Paula suggested the product owner only uses a roadmap or a mindmap for the great ideas, not the bug-tracking system. That way, the bug-tracking system isn’t a general dumping ground. It just tracks bugs.
And, the great ideas reappear.
Good Ideas Reappear
If you keep the bug-tracking system clean by fixing problems as they occur, with any luck you have a different problem. Your customers like using the product so much, they have requests. Where do you put those requests?
I recommend you put them in some form in an “options to consider” list or database. If you want to collect demographic data or other kinds of data about the request, you might need a database. Maybe you can get away with a spreadsheet. I happen to like a list, maybe with the date of the request.
Do not use the bug-tracking tool as a dumping ground for everything about the product.
The reason I use a list is that I can then add another column with the number of times different people ask for this feature. Some of my colleagues like to add the dates of the additional requests.
I use that list to see if the request still makes sense and if the request moves the product in the direction in which we want to go.
The more people use your product, the more often the good ideas will reappear. You might have choices. You might want to offer a different or adjunct product to the one you have.
When you track requests, you have a different perspective on the product than when you track problems. You see where to take the product, which will help generate roadmaps. And, you might see which problems prevent you from getting there, which helps generate more immediate backlog items for the team.
You can separate the long-term plans from the short-term plans.
Parking Lots Reduce Cognitive Load
Paula suggested a parking lot for ideas that weren’t ready for the teams. In effect, the parking lot was like the backup database copy for the bug-tracking tool. The product owners could add anything to the parking lot. And, they didn’t have to think about the parking lot all the time.
When it was time for the team to do new work, the product owner could review the parking lot and see if anything was ready to come off the parking lot.
Parking lots help separate long-term planning from short-term planning. If you don’t have to look at everything all the time, you can plan better for the short term. And, if you review the parking lot, you might see something you want to promote into the roadmap, the longer-term plans.
Delete Data, Don’t Hoard Data
It took Paula several months of working with product owners and teams to manage the data hoarding. It didn’t work overnight. However, about three months after she started, several teams were able to release more features faster. Why? They had fixed all the little irritants that prevented them from moving fast. As a result, they could respond faster to requests.
The teams were able to execute and plan better for the immediate future. That let them create more experiments for the work that was farther off.
These teams could see their most important data. They didn’t have a cognitive load from trying to manage all that data.
Avoid hoarding data just because you always have. You can retrospect on the data you use and keep.
Johanna Rothman, known as the “Pragmatic Manager,” provides frank advice for your tough problems. She helps leaders and teams see problems and resolve risks and manage their product development. Johanna is the author of fourteen books and hundreds of articles. Find the Pragmatic Manager, a monthly email newsletter, and her blogs at jrothman.com and createadaptablelife.com.
