The difference between bugs and requirements – and how to handle them

What's seems evidently different for some people might appear identical to others. Let’s see how different bugs and requirements really are.

There are different ways to look at this question...

By definition

If you look up the definitions of at the terms “bug” and “requirement” they may seem only vaguely similar, clearly distinct

Bug: “A [...] bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.” Software Bug, Wikipedia

 

Requirement: “1) A […] capability needed […] to […] achieve an objective.
2) A condition […] that must be met […] by a solution component to satisfy a contract, standard, specification, or other formally imposed documents.
3) [omitted]” IEEE, via Wikipedia

By point in time

But if you look at them by the point in time when they become manifest, they become a bit more similar.

A thing (like maybe some ‘feature’) that is not ‘available’ now, is just a requirement: “Cars should have visible (blinking) indicators that show where they want go” was a requirement before indicators were invented.

A thing that has been there once, but subsequently has disappeared, sometimes is a bug "That car's indicator should blink" is a bug report for a car on the road today.

So in some cases whether you look at a bug or a requirement just depends on the point in time you're at.

By reaction

When one looks at bugs or requirements with regard to the possible ways to handle them it somehow pays off to be sure who is looking. For now lets focus on the customer (product owner, product manager etc. – the person who pays for the things that the development team spends time on).

I don't see any reason at all to react differently – except with regard to further context.

Given that a so-called ‘bug’ surfaces in an already published piece of software that is used regularly the fixing of a bug has to have some budget allocated. And obviously it needs to be prioritized. From a business point of view this means that fixing a bug just is fulfilling ’a condition that must be met to satisfy the formally documented desired behavior’ for this bug ... sounds familiar?

If, on the other hand, the bug surfaces during the acceptance phase of a feature (or ‘system capability’) the situation is straightforward. Since the error wasn't present in the previous version of the software the new feature can't be accepted. The instruments of the respective process should be used to remedy the situation. That could be blocking the work-item, swarming, stop the line etc. – each way the error has to be fixed before the new feature can be accepted. Not a bug – just a requirement that has not yet been met.

By common (agile) sense

Now if we believe in test driven development (tdd) we start implementing each thing by writing some tests that tell us when we are done. If we follow behavior driven development (bdd) we might be able to map requirements directly to one or more bdd-specifications. Which we write first, before we implement the capability.

The first thing we do with a bug is to check whether we can reproduce it. Some people then write a test that demonstrates the bug. (according to the rule, that you just don‘t write any code that isn't required by some broken test)

So bugs and requirements are both firstly described by a test that is ‘red’ (or breaking) and then implemented – not much of a difference here.

By work item type

Now this a thing that even in my opinion justifies to differentiate between a bug and a requirement – or isn’t it?

I think in some cases bugs (from a system that is already in use) are different from other requirements in the ratio between size and value. So while most system capabilities that can be described by user stories are comparatively expensive while bugs sometimes are cheap to (e.g. with little effort) fix and yield a high value by making the user experience much more enjoyable (for example if they don’t have to confirm erroneous error messages any longer).

There is no bug

In the end a bug just is special kind of requirement. And when and whether to fix it should be a business decision just like any other prioritization of requirements. For a web-based shop-system that has the bug “’stay logged in’ doesn't work” and a feature request “Add the capability to use the most commonly requested credit card” the decision what to do next might very well favor the feature over the bug. From a business perspective it might be acceptable for a while if users have to re-enter their credentials every time, even though they activated the “stay logged in” box while not having the capability to pay by credit card can be a real problem for the business.
Some bugs are quite easy to live with, while it’s really a nuisance to live with some unmet requirements.

So – how do you handle your so-called bugs?

till next time
  Michael Mahlberg

Yes you can (because I think so)

a.k.a. “works on my machine” or “works in my world”

The Situation

Developers declare function after function ‘ready’ and the customer still complains that “nothing ever gets ready” - unhappiness ensues.

Example

This little exchange really happened…

Consultant: “Has the issue #whatever been resolved?”

Tester (customer): “Oh yes, that was the one where we couldn't do #some_important_thing”

Developer (supplier): “That's been handled for ages - you can do #that_important_thing"

Product manager (customer): “No, I still can't do #that_important_thing”

Manager (supplier): “It is possible to do #that_important_thing"

Tester (customer): “I wanted to try it this morning and it is still not possible to do #that_important_thing“

Developer (supplier): “I am sure! I have implemented that. You definitely CAN DO #that_important_thing”(in an aggravated tone)

[one or two more circles like that, voices getting louder]

Consultant: “Ahem...”

Tester: “What?”

Developer: “What?”

Consultant: “Dear Tester: _In what way_ couldn't you do #that_important_thing?”

Tester: “I don't see any menu entry related to #that_important_thing in my main screen!”

Developer: “Oh - you're trying to do it with your own account! That won't work of course …"

Tester: “There is another account?!? What's the name? Where is it mentioned?”

Developer: “Oups … we might have to work this out a little more …”

And thus both the developer and the tester learned something new about the system and its interaction with the world.

The Problem

The parties clearly communicate on different levels of abstraction – while the developer was referring to the theoretical capabilities of the system the tester was taking about the things he actually was able to do with the system at that point in time.
Abstraction differences like this oftentimes can take days or weeks to become visible, especially if the parties involved communicate intermittently and use media like e-mail or a ticketing-system for their conversations.

A Solution

Go to the real enduser (or as close to the real enduser as possible) and watch her using the newly added system-capability.

Related lean/TPS concepts

Genchi Genbutsu / Gemba Walk

Related values from the Agile Manifesto

Customer collaboration over contract negotiation
Responding to change over following a plan

Related Scrum Values

Openness
Respect

From the customers perspective...

... a story starts and ends with the customer experience. There are no technical stories.

The technical temptation

From a technical point of view two stories A and B that share some basic functionality might look like an opportunity to extract the technical commonalities in a story C. What tends to happen is that you wind up with three stories A, B, C that can be easily "estimated" and have an obvious order of implementation - you start with implementing the technical commonality C and then, once that is stable you can do A and B on a tried and trusted foundation.
Nice, isn't it?
No - it is not!
Now you would have three stories and none of them conforms to the I (independent) of the INVEST concept for good stories. And what's worse: you end up with a story that is not testable by the user - story C. To add insult to injury, it is even your first story, further delaying the deployment of code that is useful to the end-users.

A solution?

For me the solution to this scenario is to really plan, estimate and analyze in four dimensions. Take the time into account. If you implement A first then A is much bigger than B because once it is finished B gets all the development effort from A for free – or at least the part that turns out to really be usable for both A and B. So B is actually bigger on the inside - unless you travel on a different timeline where B gets developed first. In that case A would be the story that gets the benefits.
In either case, the important message is:

Don't burden the customer with technical stories to get better story-sizing, just look at every story in the context of the moment when it gets implemented.

Value gets delivered only when new capabilities are available to end-users.

Untill next time
  Michael Mahlberg