ANSWER

🎶
Potato, potahto, tomato, tomahto!
Let's call the whole thing off!
~ Fred Astaire and Ginger Rogers

It’s a defect…
It’s an enhancement…
It’s a defect…
It’s an enhancement…

Do you see where this is going?  Nowhere right!
Flip a coin.  Maybe that’s the way to resolve it?

“It is a defect, or an enhancement” is one of those arguments in software development that never seems to satisfy anyone when someone makes a decision.  I’ve gone so far as to say it is a defectment.  It’s really a combination of both.  However, that doesn’t necessarily answer the question - nor provide guidance to a resolution.  

Now, why would this happen?  It’s all about perspective.  And some other “gut” feelings, all of which are hard to persuade.  

Stakeholders & users often see a defect; why?  Because the software is not performing as expected.  They may not have been involved with requirements gathering or even thought about all the items that go into getting the software ready to use.  

The Development team, well, they often see an enhancement; why?  Because that particular requirement/user story either was not documented or wasn’t explicit enough; therefore, don’t expect it to work that way.  “I coded to the specs provided.”

You can see both cases, right!

At the end of the day, you’ll get a bunch of finger-pointing, especially when there are metrics involved, such as “What is the percentage of defects introduced relative to the size of the implementation?”  The development team ends up looking unfavorably.  As a developer, the way to turn it around is to ensure you performed all required tasks.  “It was the Product Owner or the Business Analyst that didn’t account for the scenario.”

At a high level, the team may have a point.  However, could it be possible the team should have also thought that this would be a likely feature the user would expect?  The team as a whole missed it.  The team could implement a new process or two to catch missing requirements to mitigate these disagreements.  

If asked in an interview, I don’t think there is a right or wrong answer.  And I wouldn’t expect the interviewer to look for that.  They’d want to know how you would handle the situation.  What is your rationale?  

In the end,  you must explain your point of view and resolution if the team doesn’t agree.  You can’t leave the feature or product at an unsatisfactory level.  If left long enough, stakeholders and users get restless, and due to competition and other software vendors offering similar products, they could go elsewhere.  
 
--
Angela Spring
Business Systems Analyst
LinkedIn Profile