Introducing a bug or returning a story?

Question

Agile

We had a dispute in the team today, on the topic of which nothing is particularly Googled. The bottom line is how to determine the flow of User Story testing: file the found flaws as bugs and include them in the current sprint or return the story for revision with a comment from QA which cases did not pass testing.

In favor of introducing bugs:

• Easier to navigate the history of the development of a feature - no need to scroll the comments feed in a feature, it's easier to refer to specific bugs
  
• Defects in a feature given for testing are the same bugs as bugs in the delivery
  
• Bugs can be prioritized, low-priority bugs can be placed in the backlog and included in the story in the delivery
  

In favor of the return of the story:

• All tasks in a sprint can be assessed - bugs from a regression or a sale can be assessed, and feature flaws are included in the feature assessment. The sprint scope remains fixed.
  
• A competent division of the task into stories is stimulated - too many developers should not work on the task, the number of comments should not grow in order to prevent confusion in the future
  
• Flaws in the store are not the same as bugs from the sale or regression, they must be implemented within the story
  
• There is no way to include an unfinished story in the release, bugs do not accumulate in the backlog
  
• It is possible to avoid introducing intersecting bugs across the store by testers, since the development history is centralized and flaws are introduced into it
  

What do you think? Please share your experience.

Answer 1

for me, each team should decide how it is more convenient for them on the current project and, accordingly, the current phase of the project. Sometimes it’s more convenient to file individual bugs if the second half of the development of a large epic, sometimes it’s more convenient to comment in a story (if there are few bugs and the story is simple), sometimes it’s more convenient just to an electronic document (when development is only in the beginning-middle and a lot of things don’t work)

Answer 2

Definitely start bugs separately from the story, but link them to the original task for status tracking. As an option - do subtasks, if the system allows it, if you don't like the idea of ​​closing a story with unfixed bugs :)
If you just return a story with comments, it's hard to assess at a glance how bad everything is.
It's hard to keep track of what's fixed and what's not.
Information on bugs can be lost.
In principle, the status of such a story is not very clear.
In general, there will be confusion on the board very soon, and stand-ups can be in style
- Why is the story not moving?
We're still fixing the bug!
- Which?
- Well, which was described there in 7 and 13 and 15 comments ..
- Uh .. (opens comments, reads, tries to understand) .. What is it about?
- Well, about [this nonsense]
- Ah, ok!
And if the bugs are separate:
- Why was this story not moved?
- Fixing bug WTF-512
- So, "It doesn't work [this nonsense]".. ah, I see!

Answer 3

Do it the way you agree. Do not engage in letter-writing, you are only wasting your time.