Don't manage enhancements in the bug tracker

As development progresses we inevitably run into functionality gaps that are either deemed as enhancements.

These issues often get captured by QA in the bug tracker and assigned to a developer that will be unable to resolve the issue.

Assigning issues to the wrong people will cause the defect to bounce around like a hot potato and waste everyone's time.

Enhancements are a requirements defect that can not be resolved by either QA or the developer.

The life cycle of a defect and the life-cycle of a enhancement are two entirely different things.  A defect is a difference between a stated requirement and the code. If there is no documentation then there is no code defect (see It's not a bug, it's...).

Most enhancements will eventually be coded by some developer; they just should not be managed from the bug tracker. They need to go through the requirements process to determine whether or not the change will be made.  Even when changes are made they can be very different from what QA or the developer expects.

Defect Life-cycle

The defect life-cycle is well known:

• Defect is identified as a departure from the requirements
• Defect is assigned to a developer
• Defect is corrected
• Correct is verified
  • If not corrected re-open and re-assign to developer
• The defect is closed

This is the correct way to manage a defect.

This is the incorrect way to manage enhancements. When QA discovers functionality not covered by the requirements then we have an issue; however, it is unlikely that it will be resolved by a developer.

Therefore assigning enhancements to developers is simply going to waste time because neither QA nor developer should be deciding requirements.

Non-Code Defect Life-cycle

There are defects that are not coding defects, this includes:

1. Insufficient requirements
2. Correct requirements but incorrect test plans

Enhancements are really requirement defects. Enhancements should be logged as such in the bug tracker and assigned to the person in charge of requirements (business analyst or product manager).  Those individuals should be responsible to track down how these issues should be handled.

If the requirements are correct and the test plans are defective then it should be logged as a test defect. This is tricky because QA often controls the bug tracker and may not  log errors that they commit.  This is typically reported in QA with a  functions as designed status.

At a minimum, the implementation of requirements and test defects in the bug tracker can do several positive things for you:

1. It removes the responsibility to find a solution from development.
2. It makes it clear how many defects are in the requirements or test plans.
3. It reduces stress; no developer wants to be blamed for an issue that is not his.
4. Many enhancements call for updated project plans and pushing back the deadline.

Put Responsibility Where it Belongs

The creation of requirements and test defects in the bug tracker goes a long way to cleaning up the bug tracker.  In fact, requirements and test defects represent about 1 out of 4 of defects in most systems.

The percentages break down as follows:

• Requirements defects: 9.58%
• Testing defects: 15.42%

The creation of requirement and test defects in the bug-tracker alleviate pressure on the engineering department and redirect it  to either the product manager or QA. Eventually enough data will accumulate in the bug-tracker to get management's attention.

At a minimum, these defect categories should help reduce the amount of fire-fighting at the end of a project..



See also:

• Root cause of 'Fire-Fighting' in Software Projects
•  Bug Tracker Hell and How to Get Out! 

It's not a bug, it's...

When does a bug become a bug?

Who decides that it is a bug?

How many legs does a lamb have if I say the tail is a leg?  The answer is 4, just because I say the tail is a leg does not make it a leg!

Bugs should be obvious, but we say It's not a bug, it's a feature because often it isn't obvious.  Watson Humphrey felt that we should use the term defect and not bug because most people don't take bugs seriously, so let's use the term defect instead.

So when does a defect become a defect?

• When quality assurance tells you that you have a defect?
• When product management says that it is a defect?
• When the customer says that it is a defect?

The answer is: none of the above. Now it might turn out that there is a problem and that code needs to change, but a defect only exists if:

code behaves differently than the requirements specification

This is important because most systems are under specified (if they are specified at all :-) ). Code can only be considered a defect if it differs from the specification.  We call defects undocumented features because we know that the problem is that the requirements were never written.

Incomplete and Inconsistent Requirements

Many organizations do not create sufficiently complete requirements before starting development, either because they don't know how to capture requirements properly or because they don't have resources capable of capturing complete requirements.

Incomplete (and inconsistent) requirements and unrealistic deadlines often force developers into making decisions about how to implement features.  The end result is that developers are regularly told that they have defects in their code.

While this process is common, it is destructive.  When requirements are under specified and inconsistent developers end up needing to perform serious rework. The rework will can require dramatic changes that will impact the architecture of the code.

The time required to find a work around (if it is possible) is rarely included in the project plan. Complicating matters is that the organizations that are reluctant to spend time creating requirements also tend to underestimate their projects.  This puts tremendous pressure on the engineering department to deliver; this promotes the 5 worst practices in software development (see Stop It! No… really stop it.)

When poorly or undocumented systems require changes that are not specified we should  call them change requests rather than defects.

Only 54% of Issues are Resolved by Engineers

The attitude that all defects must be resolved by the engineering department is severely misguided.  Analysis by Capers Jones of over 18,000+ projects shows that only about 54% of all defects can be resolved by the engineers! (only the 3 highlighted rows below)

Defect Role Category	Frequency	Role
Requirements defect	9.58%	BA/Product Management
Architecture or design defect	14.58%	Architect
Code defect	16.67%	Developer
Testing defect	15.42%	Quality Assurance
Documentation defect	6.25%	Technical Writer
Database defect	22.92%	Data base administrator
Website defect	14.58%	Operations/Webmaster

This means that precious time will be wasted assigning issues to developers that they can not resolve.  The time necessary to redirect the issue to the correct person is a major contributing factor to fire-fighting

Getting Control of the Defect Process

For most organizations fixing the defect process involves understanding and categorizing defects correctly. Organizations that are not tracking the different sources of defects probably have a bug tracker that has gone to hell.  Here is how you can fix that problem, see Bug Tracker Hell and How To Get Out!

At a minimum you need to implement the requirements defect, once you identify issues that are caused by poor requirements it will shine the white hot light of shame onto the resources that are capturing your requirements.

Once you realize how many requirements defects exist in your system you can begin to inform senior management about the requirements problem.

Reducing Fire-Fighting

The best way to reduce fire fighting is to start writing better requirements (or writing requirements :-) ).  To do so you need to figure out which of the following are broken:

1. Not enough time is allocated to the requirements phase
2. Unskilled people are capturing your requirements

In all likelihood both of these issues need to be fixed in your organization.  When requirements are incomplete and inconsistent you will have endless fire-fighting meetings involving everyone (see Root cause of 'Fire-Fighting' in Software Projects)

Stand your ground if someone tells you that you have coded a defect when there is no documentation for the requirement.

Stupid is as stupid does

Senior management does not set out to have failed projects, yet 7 out of 10 projects fail and you wonder why they keep doing things the same way.

As Forrest Gump's mother stated, "stupid is as stupid does", that is, smart people sometimes do stupid things.  Most senior managers are pretty smart, however, managers end up doing some very stupid things.

Now from a human perspective, something very interesting is going on here.  For example, suppose you were give the following choices:

1. An 80% chance of making $100
2. A guaranteed $50

Choosing the 1st alternative has an expected value of $80, so people might be expected to choose this because $80 is more than $50. However, because humans are risk averse, almost everyone will choose the second alternative with guaranteed money.

Now out of 10 software projects:

• 3 will succeed
• 4 will be challenged
• 3 will outright fail

To put that in perspective, if you were watching people cross the street at an intersection:

• 3 cross the street successfully
• 4 get maimed
• 3 get killed

How interested would you be in crossing that street?

Stupid is as stupid does...

You can Google "software project failure rates" to see that this has been demonstrated reliably over many industries over 50 years.  Challenged projects are over budget and under deliver but senior management manages to sell them as victories.  I do not consider challenged projects to be successful; hence the statement that 7 out of 10 projects fail.

So if human beings are risk averse and the odds of project success are so low then:

Why does senior management ignore risks on software projects?

It seems likely that senior management can't conceive of their projects failing. They must believe that every software project that they initiate will be successful, that other people fail but that they are in the 3 out of 10 that succeed.

This inability to understand the base rate of failure in software development is systemic. There are so many software projects that are started by senior management where the technical team knows that the chance of success is 0% from the start.

Senior management is human (seriously, they are :-) ) and is risk averse, you just need to find a way to remind them of this. One way to get senior management to think twice about projects is to make sure that there is a meeting before launching the project where management is asked the following question:

Assume that this project will fail, why would it have failed? What will the consequences be?

This exercise (if done seriously) may have the effect of causing senior management to realize that the project can indeed fail. With luck, the normal risk aversion that every human being is endowed with will kick in and the project may get re-evaluated.

Stupid is as stupid does...

Related Articles

• Why Management Declared Deadlines Lead to Disaster
• Stop It!  No... really stop it
  • Article about the 5 most common worst practices in software
• Shift Happens
  • Why scope shift is inevitable in software projects

Bibliography

Kahneman, Daniel. Thinking, Fast and Slow.

Kahneman explains why it is human nature to ignore base rates of failure and why we over-estimate our chances of success in any venture.