When the specification and the agreed behavior of the application operates without fault, however the outcome turns out to be undesired, what should this be called? Is it a bug?
How can it be a bug when the software performs as desired from the specifications and the agreed behavior?
I do consider this a bug. In my experience 90% of all bugs* are about not understanding what is wanted: ie. design bugs.
In this case the design itself was buggy leading to a bad specification. The fault here lies not in the person who implemented the program but in the person/team who designed the system in the first place.
In a Scrum setting, I usually consider fixing design bugs as completely new stories since it really results in a new specification (and along with it new tests and new definition of done). I don't consider it a "bugfix" task.
*note: In most modern languages. In C, 90% of all bugs are about bad memory management
I would have thought that the result was part of the agreed specification. Which would mean that the program is not behaving as specified. Either that, or the expectation of the result is flawed and the program is showing the correct result.
This is a faulty specification. If a programmer makes mistakes implementing the spec, these are bugs. If the spec is faulty, but implemented correctly, this is a feature ;-).
Yes its a defect.
But its a defect in the specification.
This in turn could be a defect in the requirements gathering.
This could either be the analyst misunderstanding the users request, or, the user requesting the wrong thing or usually a mixture of both. (But I always blame the analyst! --- on the same basis that you would still blame a doctor for mis-diagnosis on the basis of poor communication with an inarticulate patient).
In theory this is the same as any other defect - report it, fix the spec, recode and retest.
However in practice these can be a real pain as they cross organisational , and often company boundries. If you are a subcontracting software company and you produced the software according to the specs then contractually this is not a defect in your software, you should get new, better specs and be paid extra to code to the new specs.
Why does it matter how we call it? It looks to me that there is a deeper problem out there where you are - instead of realizing there is work to do and doing it ground is being prepared for blame-laying. This serves no purpose and everyone wastes their time.
I understand the frustration on both sides, but right now what you have to do is a) identify what has to be changed for the software to work as expected (and therefore bring users the benefit they hoped for) and b) do it. Call it a bug or call it a new story - or call it a butterfly if it helps, but move forward.
People from TDD background say that "a bug is a test that was not written". With that in mind, this unexpected behaviour is a test that was not written, because of a specification that was not included.
The agile movement is about delivering good products. That's why it's not important to set a fixed set of requirements to implement according to a contract but correcting and improving the direction of the team at each step (iteration, sprint, etc). So with that in mind I'd say that if you face an unexpected behaviour simple stablish what's the expected behaviour write new stories/test cases that you can verify against and include then in the next sprints.
Change is everything.