As you probably guessed from the title, I recently became a father. The number of poopy diapers we had to deal with in the baby’s first couple of months shocked me. Although I tried to read up before the baby arrived. As a former developer and current business analyst, I could not help but wonder: Do I have a buggy baby? Or are these diapers an undocumented feature?
I didn’t think too much of it. But after some time I had a disagreement with a developer on whether a bug submitted by the QA team was a bug or a feature. And I asked myself the wider question:
When is a bug a feature request and when is it a reasonable expectation of a user story?
To answer the question, I first searched for the definition of a bug. There are plenty to be found, but this definition from Software Testing Fundamentals resonated with me:
A Software DEFECT / BUG / FAULT is a condition in a software product which does not meet a software requirement (as stated in the requirement specifications) or end-user expectation (which may not be specified but is reasonable). In other words, a defect is an error in coding or logic that causes a program to malfunction or to produce incorrect/ unexpected results.
The part that resonated was “end-user expectation (which may not be specified but is reasonable)”. But that’s probably because I’m the one writing the software requirements in my team.
Dalip Mahal argues that a defect only exists if code behaves differently than the requirements specification. His argument is that many organizations do not create sufficiently complete requirements before starting development.
He further argues that incomplete requirements and unrealistic deadlines force developers to take decisions about how to implement features which inevitably result in bugs.
While this is true on some projects and in some companies and probably more so when using waterfall methodologies, it also sounds like a blame game. Where the developers blame the business analyst that an outcome was not specified while the business analyst claims that the expected outcome was obvious and did not need documenting.
Thinking back to the disagreement my colleague and I had, I tried to understand why we had debated so much on whether the issue found was a bug or a feature. And then I found Jeff Atwood’s article That’s Not a Bug, It’s a Feature Request that raised two really interesting points:
There’s no difference between a bug and a feature request from the user’s perspective.
But, by having this dichotomy of bug or feature it pushes some developers to label things they don’t want to do as feature requests. That’s because they hope that these new features might never get done.
That’s when it struck me: I thought our baby was buggy because I didn’t want to change the poopy diapers!
Another reason we tend to have the bug vs feature debate is ego.
BAs don’t like to hear that they haven’t covered everything in their user story and acceptance criteria so they tend to say “it was implied”, while developers don’t want to admit that although not explicitly stated, it’s reasonable to expect a certain outcome to be covered by a user story.
Then there is the whole planning and prioritization discussion. People assume that if they submit a bug on an incomplete functionality it will be done sooner than if they submit a feature request to do the same thing.
Here, I really agree with Ernest Mueller’s opinion that, in an organization where the focus is on the end users, no one should really care whether something is a bug or a feature as long as it brings value to the end users.
So, the next time you find yourselves having this debate ask yourselves:
Does it really matter if it’s a bug or a feature?
Just do it and bring value to your customers!
PS: It turns out that people have extensively documented poopy diapers. But, like a former developer that I am, I just didn’t read the entire acceptance criteria. 🙂
Icons made by <a href=”https://www.flaticon.com/authors/smashicons” title=”Smashicons”>Smashicons</a> from <a href=”https://www.flaticon.com/” title=”Flaticon”> www.flaticon.com</a>
