How to handle User Story bugs found while testing a particular User story? Does agile process promotes logging of Story bugs ?

Does agile process promotes logging of Story bugs ?

Hi Mandar - Scrum thrives when Development Teams self organizes their own work.  Therefore Scrum is intentionally less prescriptive, leaving the solution up to the teams.  Teams typically come up with the best solutions to their problems.  And they are more likely to buy in to the solution if they collectively came up with that solution.

How should these bugs be handled in the same sprint? Should they be communicated verbally to the developers? or should they be tracked as linked task in the same user story (with identifying it as a bug with a label)

Perhaps the answer will be "Yes" to both suggestions.  As a developer I always valued the conversation with the person who found the bug, versus the bug being logged in a tool.  And, regarding the bug being tracked, might it be beneficial to visualize the bug and its related story to aid in radiating information to the Scrum team?  Perhaps they will find an even better way.  A Scrum Master will not find the answer and provide it to the Scrum Team - rather, the Scrum Master will create an environment where the Scrum Team will self organize to find their own solutions.

Chris

In one of the user story we have 2 bugs, due to which story cannot be marked as done.

That is the key statement in your question.  If the stories can't be marked as done, why would they not be fixed?  Do you need to have a formal record of the bug if it is fixed before the work is delivered?  What benefit does that provide?  It is sort of the old "if a tree falls in the woods, does it make a sound?" thing.  If a bug is fixed before it is released to production is a really a bug?

From the way you phrased the question it sounds like your Dev Team is made up of developers and testers instead of just team members doing all types of work.  That is fine as long as the team decided it would be that way.  But since one of the premises of Agile/Scrum is to communicate, why not just have the tester sit with the developer, show him the problem, developer fix it, tester validates?  It would be much easier and faster to communicate the issue.  And that is coming from a person that has done QA/Testing for almost 15 years before becoming an Agile Coach.

@Chris is spot on with the self-organization statement.  What does the team feel is the appropriate way to handle it?  

due to which story cannot be marked as done. How should these bugs be handled in the same sprint

As Daniel already said, this is the key statement in your question. In my opinion if the story cannot be marked as done, then the bugs must be fixed in the Sprint.

Let me describe how we do it in my current team:

When a team member finds a bug, it uses a tool to log it and must provide clear and easy to understand steps to *reproduce. This helps to avoid distractions and allows developers to best organize their **work. If the bug blocks the story from being marked as done, then the original story is "reopened" and the bug is inserted into the ***sprint. If there are bugs that are not blocking the story, these are inserted into the product backlog by the dev team ****members.

It is important to note however that we reached this process after failing multiple times and discussing the reasons during our retrospective meetings. No one forced the team to use a logging tool and no one suggested how they should organize their work, they did that themselves and that's what a Scrum Master should do :)

Having said that, I believe that you should have a discussion with the team and explain why the bugs must be fixed within the Sprint (violation of DoD). Then in your retrospective meeting, bring it up (or even better wait for someone else to bring it up) and discuss how you should adjust your process and what tools/methods you'd like to use. Don't force anything on them, let them decide as they know best.

Hope I helped :)

* The team suggested each bug ticket must have clear steps to reproduct during a retrospective meeting as we had issues when we first started.

** Again the team proposed it during a retrospective meeting. They said they were often being distracted by other team members and were unable to focus on their work and be productive

*** In a retrospective meeting we discussed with the team that we cannot move bugs to another sprint if they violate the definition of done for a story.

**** Again, agreed upon by the Product Owner and the Development Team during a Retrospective meeting

In one of the user story we have 2 bugs, due to which story cannot be marked as done. How should these bugs be handled in the same sprint?

I imagine that a team may wish to swarm on those defects as a priority concern, given that they present an immediate inspect-and-adapt opportunity where any delay is likely to result in waste being compounded.

Aside from that consideration, why wouldn’t they be handled the same way as any other collaborative activity required to achieve Done?

 In one of the user story we have 2 bugs, due to which story cannot be marked as done

Your stories cannot be marked as done because your Definition of Done should include at least making sure the PBI (be it user story, functional requirement, NFR,  or whatever format you use) is bug free for two reasons.

The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created. - Scrum Guide

During the Sprint: Quality goals do not decrease - Scrum Guide