The Feeling of Rejection

In scope or out of scope? This has got to be one of the most common issues that we face when raising defects. I raise an issue that then comes back as rejected because the documentation isn’t specific enough around that area and development is often focussed more on time and effort involved than usability.

There are four possible outcomes:

  1. The defect remains rejected and is ultimately closed
  2. The rejection is overturned, and the defect is accepted as valid, and fixed
  3. The rejection is valid, but leads to a change in the documentation, and in turn, a fix to the defect
  4. The rejection remains, but the issue is progressed to an ‘Enhancement’ or other suitable status, to be addressed as part of some future release.

Which outcome should you push for?

As with everything in our craft, it’s all down to the context.

Ask yourself five questions

  1. How likely is the defect to occur?
  2. How severe is it?
  3. How easy is it to fix?
  4. Is there a workaround?
  5. Is this internal, or external facing?

The combination of the first two questions gives you an ‘impact assessment’. You can go as far as scoring each answer and multiplying the two to give you a figure (management loves to report on figures rather than words).

The third question should then be considered in light of this assessment. If it’s easy to fix and has a high impact, then push for an immediate fix. If it’s very difficult to fix but has a low impact, you might want to let this one slide.

Question four adds a bit more qualification – if there’s no workaround available then you are in a better position to push for the fix now. If there is one available then maybe it can wait a while.

Question five is probably the most important one. If this is external, then it can be a real game-changer, as suddenly even the smallest of defects can cause real damage to a brand if exposed to the public. If it’s internal, then the opposite is true, large defects can then be handled by ‘business process’, ‘workflow’ or my favourite, as a ‘training issue’!

Consider a spelling mistake on a page. Normally it’s not a huge issue and a few of them often get through. Consider though that this is a website for a company selling English language educational assets. Having a spelling mistake on your front page is likely to cause people to think twice before purchasing from you.

Ultimately though, any software is a solution to a problem. If the problem isn’t solved, then the solution is broken. If the solution is broken, then a defect needs fixing.



  1. That is so true. The context of anything is such a game changer in “selling” any bug to management as something that must be fixed. Ironically, the lower priority a bug, the more work there can be to do in convincing others that it needs to be fixed. I always show ppl this ( as a great example of how mere typos can create a bad impression

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s