Skip to content

Bugs bugs bugs bugs

September 2, 2013

Pain

It has been a while since I wrote my last item. So it seems like the right moment to start about the pain of product ownership. Over the years I have been in product management I have been confronted with a number of Big pains. The big three are Bugs, New architecture and New product.

As a product manager I consider adding some functionality to an existing product the easiest part of my job. You may need to overhaul something to get it done, but in general it is just adding the thing you want to add and make sure it fits GUI schema and workflow of the user. But if you are a real product manager these things come by nature.

Bugs cost

The first pain is really Bugs.. Your natural response on bugs is to fix them, and you should. But hold your horses. There is more. Bugs are the biggest enemy of your new functionality developments. Bugs cripple innovation. The cost of a bug exists out of:

  • sad customer experience
  • cost to fix
  • cost of missing the opportunity to build new functionality

And the last one is really the major one. It is my believe that fixing a bug is softening the pain of a customer, but new functionality can really take away the pain. So you always try to deliver new functionality. But, of course, there is always a balance. (did I already mentioned that I hate nuances..)

Quality

If the number of bugs is growing, and regression bugs start to appear, there is something more you need to do. You need to know about the quality factors in your production. Is your product being coded according to all the quality standards? Are there unit tests, are there automated tests and run all these tests with checkins and builds? You need to know..

And over time you will discover that building a sustainable product can only be done based upon the best development standards. Even while you are a product manager, you should want and demand these standards. There is no excuse for not creating unit tests and automated test cases. And manual testing is not adding quality to a product. Quality is something that is transferred from one version to a next version.

Manage your bugs

How do you manage your bugs… I prefer not to.. 🙂 In my current role we have solved it in the following way. We have made a historical estimation of average time per two weeks spend on bugs. This average is the reserved bug budget in the sprint. Next we have given this budget to the Customer Care Manager and lead engineer in second line support team. These two deliver every two week their priorities. These priorities fill in the bug budget. Of course the content is overlooked by Product management. This allows product management to focus more on moving ahead and pulling the product forward. But at the same time every sprints delivers a stable balance between fixes and new functionality. But the best thing of all.. the hard choices of which bug is fixed in the next sprint is made by the people closest to the user that feels the pain. As a product manager you should be really careful with increasing the bug budget.. in general there is no reason to do that. In fact, it should go down.

And for the one that wonders.. you should not fix every bug. There a loads of bugs that simply do not get through the cost-benefit equation. But that could be a subject on itself again.

Next blog will be on the second biggest pain of a product manager.

Advertisements

From → Uncategorized

6 Comments
  1. Interesting to see that you are using estimates of the amount of bugs in the product, based upon what has been found previously. Which helps you to balance quality and new functionality.

    I worked with teams where we estimated the number of bugs also for new stories that would be developed (as described in http://www.benlinders.com/2012/steering-product-quality-in-agile-teams/). The purpose was to discuss and agree up front on the quality that was needed. Aligning the needs of the users with the process that the team would use. If higher quality was needed, the team could decide to do more reviewing, pair programming and testing. It would take more time to develop the software, but the price would be acceptable for those user stories. Where a lower quality level is sufficient, teams actually reduced testing and saved time and money, and delivered faster.

    • Love to understand more about the steering of quality. In my believe that is only one standard… the best. But that could be that all the products I have owned are products that have a very long life cycle.
      But is do struggle with the idea to reduce quality to reduce cost. Within a certain range this could work… but there is a point where reduce with turnaround in increased cost.

      I will be reading you blog to understand more. Thanks for replying!

      • You have to find a good balance in quality, cost, schedule and functionality for your products/customers. Which often turns out to be difficult, but not impossible.

        In the example that I mentioned, the purpose what not to reduce costs, but to have a shorter delivery cycle to collect feedback from the customer. We wanted to find out if we were building the right product.

        Nowadays you would call it lean startup, but at that time the term wasn’t invented yet…

      • Been through your blog (link in previous response) and I really like your second example. Think the definition of a bug has changed over time. In the old Waterfall days things that where called bugs are now just the results of a first iteration.
        Think that it is important that in sprints you are not only building the functional elements one by one, but also grow the functional elements over sprints. (at least.. if they are not too small).

        The great thing of lean is that now the rest of the business finally understands the thing we are doing with Scrum.
        Btw, you second case is also a great example of how to reduce waste…

  2. Hi Emile, nice that you are sharing your experiences on this matter with us. It is good to hear that Product management is still involved in how the bug budget will be spent as every decision to fix a bug should ideally be based on a cost-benefit analysis.

    I was wondering: do you track the number of bugs and their severity/impact? Apart from automated tests, did you have to take other actions to reduce bugs?

    In our case, reducing the story size and raising the importance of ready stories (with the Definition of Ready) has helped us a lot already. Now, it often takes at least a few small stories to implement new or to change existing features.

    • Tracking of severity and impact is done in TP (jira like app). This allows us to do all kind of reporting so we should be able to detect trends. But.. we are coming from a situation without unit tests and limited automated tests. Unit tests are there of course next to automated tests. Unit tests are an absolute must. Let no one tell you ever that you do not need them.

      Story size reduction.. yes, small is important. Not bigger then 10sp, otherwise it needs to be broken down in smaller parts.

      Definition of ready. Do not have discussions about what is needed for the DoR.. there is only one thing needed: a proven mutual understanding of the story. And this proof you can only have if you communicate with each other. As a PO you are responsible for making sure the team understands. So you should check this continuously by checking if they ask questions about a story, looking over their shoulders while they are building, asking for a quick screenshot, etc.
      DoR is often used to make you write loads of useless text so you can possibly avoid a few questions being asked. That is wrong..
      A story is and remains an invite for a discussion on functionality. A story that fails to trigger questions is a BAD story. So.. in short… DoR does dot reduce bugs, lack of communication does.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: