That’s Not a Bug

Dictionary definitionI do a lot of Atlassian tool configuration for my job as a consultant at Adaptavist, and one of the most common things I hear about halfway through, or soon after, an engagement is that there’s a “bug.” Something isn’t working the way the customer expects it to, and therefore either the software is buggy, or something was misconfigured.

The vast majority of the time, these reports aren’t actually bugs, and instead represent a misalignment of the client’s expectations and the specification that we had for the configuration. The bug report really ought to be filed as a change request, or potentially a new feature.

It’s important to differentiate between bugs, changes, and new features because the review and approval process is different between them. The amount of work needed to handle them is different as well. A bug should be fixed automatically because it is helping achieve the original desired goal; a goal that has already been reviewed and approved.

Changes may need to go through a different review process, and stakeholders may need to be informed that there is going to be a change to a configuration that has already been reviewed and approved. Where fixing a bug is bringing a configuration or feature in line with the original specifications and documentation, a change request has greater impact. The amount of work may be similar, but the context of the work is different.

A new feature is something else entirely, even if it is related to an existing feature. If something was left out of the specification and represents a significant enough change that it qualifies as a new feature, then we need to make sure that everyone is on the same page when it comes to the configuration required, who needs the feature, what they need it to do, how long it will take to implement, etc.

Because these three words or phrases represent three very different kinds of work, it’s important that we use the right language. We can’t call everything a bug just because something isn’t working the way we want it to. If we want to get the right results, we have to use the right words.

3 thoughts on “That’s Not a Bug

  1. I think the major difference between the work for a bug and the work for a feature (or any other change) is just the element of surprise. Bugs are less expected than new feature requests.

    My wish is that people would report problems with:

    1. Steps to reproduce
    2. Expected behavior
    3. Actual behaviour

    plus a summary, context, screenshots, how long it’s been happening and how annoyed are they

    I had a report last week that said “JIRA IS NOT RIGHT” (sic)

    1. One client I work with has those three as custom fields on bug reports.

      Often, the summary is something like “XYZ is broken” and either #2 or #3 are filled out, but none of the others.

      For improvements or new features, we need a story. For bugs, we need expectation and deviation. For all of it, we need communication 🙂

      1. I know, and if you make them required they just fill it with: asdasdasd
        Communication and setting of expectations. And some grade school education I think, about how to report a problem. At some effort I have trained my family in this. They give me funny looks now

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