When is a bug a story and a story a bug

Question

I'm currently debating what constitutes a bug and a story.

1. If there is no evidence for expected behavior then, Are all perceived issues are bug?
2. If a change is made in a story that wasn't detailed in the criteria of the case, is that a bug?
3. Is any additional change not specified in a case a story? Even if it seems like a bug. e.g. is so obviously wrong that the oversight in the case should have been spotted.

How far should you go with this train of thoughts? It feels overly pedantic but I'm trying to weigh up the benefits of being more rigid with the propositions above.

Answer 1

In short:

A user story describes desired behaviour of the system focussing on results and written in plain understandable language. More formally:

A user story is a tool used in Agile software development to capture a description of a software feature from an end-user perspective.

A bug is something wrong in the system. Either a violation of requirements or something that will bother a user.

A software 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.

That being said,

1. If there is no evidence for expected behaviour then are all perceived issues a bug?

This means you need to talk to the developer and/or use common sense,

2. If a change is made in a story that wasn't detailed in the criteria of the case, is that a bug?

Now you have an problem with procedure that does not necessarily means a bug is caused,

3. Is any additional change not specified in a case a story? Even if it seems like a bug. e.g. is so obviously wrong that the oversight in the case should have been spotted.

It should be the other way around, a use case should hold more detail than a story. There may not be a neat mapping between them anyway of course.

It is always difficult to stay focused as a team while changes sweep through the already worked on features. That is why no such changes should be allowed during sprints. The above suggests that some mix-ups got in as there seem to be mismatching versions and/or discrepancies in the work to be done. Time for some Backlog Grooming?

Answer 2

Agree with Bookeater.

A bug is anything that affects the value of the product. This can be an error, poor performance, a security breach, poor user experience or even poor execution of a feature.

A story is a short description of a behavior. Explained by the business in a language and format that can be understood by developers and business people alike. It is not meant to contain a lot of details since its purpose is not to describe the implementation.

Any misses stating the desired behavior, implementation and execution of the feature will qualify as a bug as long as it affects the value of the product. I state the value of the product because if a new design is rolled out for a site and the font face was not specified, but the type used does not affect the site. Users can read all the information they need and information seems to display fine, then this would not be a bug even though is something that wasn't specified.

If a story changes enough that the initial request is buried under new variables then that should be considered a new story and worked on around that basis.