Should it be Bug or User Story?

Does it really matter what the ticket type is?  There is something that needs to be done for the product.  You can convey that information no matter what the ticket type is.  Scrum doesn't say anything about stories or bugs. It just has a Product Backlog Item that will become a Sprint Backlog Item.  As far as the Scrum framework is concerned, the item could be written on the back of a cocktail napkin as long as it provides enough information for the Scrum Team to recognize the value and identify the work. 

I advocate that we my teams use only one type of item.  It is called an item.  That way everything is seen and treated equally. 

There is no Scrum answer for your question.  That is a process issue and in the Scrum framework process is left up to the individuals doing the work to determine. 

Originally, a "story" was just a placeholder for a conversation between the developers and stakeholders (the on-site customer, a product manager, a small group of users...). Then, people came along and created different formats for expressing stories. The "user story" format came out of Connextra, and there are other types of stories as well. I would recommend not getting too caught up on formats, but stick with the idea that a "story" represents some unit of work that is understandable by and valuable to at least one stakeholder.

Given this definition of a story, a bug can be a story. You can explain the bug to a stakeholder and they would understand what it is and be able to assess the value of working. I would consider anything that enables a conversation about what the product should do and how to get there to be a story.

In Scrum, there is only the notion of "Product Backlog Items". What they are doesn't matter. Product Backlog Items can represent new development, modifications to existing elements of the product, bugs to be fixed, and technical debt to be performed, or even documents to write. Scrum says nothing about classifying Product Backlog Items in different ways. Stakeholders (including the team) may find this categorization adds value. Other times, debating the difference between a requested change and a bug just adds waste and the categorization isn't necessary.

I would agree with your developers that something needs to be captured to determine this work, especially if the work has been released and delivered. This something, in Scrum terms, is the Product Backlog Item and the Product Owner can order this new work on the backlog. If the work is still in progress in the current Sprint, then it may be more dependent on the situation. If the team feels that they can't complete the work with the additional information within the Sprint timebox, perhaps the work should be deprioritized and put back into the Product Backlog. In other cases, perhaps it's OK to let the team deliver the work as they understand it and create a new Product Backlog Item for the remainder of the work. Regardless of the outcome, it may be useful to spend some time in the Sprint Retrospective to understand why the refinement activities missed this chunk of work.

The distinction between "developer" and "tester" is also anthetical to the idea that there are no sub-teams in the Scrum Team.

I told them this is a logic and it shouldn't mentioned in old user story because user story doesn't have to have all details and scenarios, this should be a tester job to check all scenarios and make sure everything is handled right way. 

Let the team write it as a user story, if that's what they want. Refinement is a team activity and is not a one-person decision.

Focus instead on the transparency currently afforded by the Definition of Done. That's where the trouble seems to be.

In my company we sometimes have that same discussion, bug, request, enhancement, change etc. 

What it boils down to though is, did the team record it so that it's visual and on the backlog? And from there the PO can help prioritize and maximize the value, regardless if it's a bug, userstory or whatever title you want to put on it.

But ...

"bug, request, enhancement, change etc. "

... do not actually exist in Scrum, there are only "Product Backlog Items". So it's your own definition.



I'm going to guess the different names for items are because that has an effect on velocity? ... and "fixing bugs makes the team look lazy because the velocity is lower".

But ...

"bug, request, enhancement, change etc. "

... do not actually exist in Scrum, there are only "Product Backlog Items". So it's your own definition.

>> Yes, that's only the case in our situation merely for categorization of each PBI. The point being is that they are visible in the backlog, and ready for deliberation with the PO in terms of the value.

It is neither a new story or nor bug !. To me, it should be the same story that goes back to your development status.

Ideally the complete scope of story should be made release ready by end of the sprint.If story is not meeting the quality standards completely by end of sprint that story should not be considered 'Done'. 

Keeping the bug open and closing the story for velocity purpose doesn't deliver its intended value.Can we tell our customers that we are releasing this feature but with a defect ? 

it shouldn't mentioned in old user story because user story doesn't have to have all details and scenarios

You point is right. User story format is definitely not a requirement or scenario document. But find it out why all the team members are not in common understanding about user story(Perhaps some teams follow 'Acceptance Criteria' for each story. It depends on how it will help your team)

this should be a tester job to check all scenarios and make sure everything is handled right way. 

Quality is everyone's responsibility in the team. More over, it should be build-in not tested in.

Again all these common understanding should be there in the team otherwise the whole team will loose time in such kind of debates.

Although I do agree with others about the importance for the decision to be taken collaboratively, I think the type does matter for two reasons:

1. Metrics

User stories (features) and bugs do play their own role in different metrics. If the team is consistent at capturing bugs then this can be a good indication of escaped defects that go to production, and this by itself can be useful. (e.g. to identify patterns, problematic areas, increases of bugs, software quality etc.)



2. Opportunity to reflect upon things

A missing feature is different to an escaped defect. They can reveal different types of issues, such as poor product design, inadequate capturing of requirements, poor refining some I can think of now.

 

To me if the requirement was not there at all, I'd consider it a feature as it was missed by product. If the requirement was captured and not implemented for any reason, I'd consider it a bug. In all cases, I'd reflect with the team upon this.

Hope this helps! 



Tony G