While you did not explicetly mention that you were doing Scrum you did indecate Sprint Planning. The guidance in the Professional Scrum Developer training, aimed at teams working on software, and derived from the Scrum Guide is that there are two sorts of bugs:
- In Sprint Bugs - Any problem that is discovered during the Sprint on work that is part of the current Sprint is not a bug that needs tracked. We are still inside of the Sprint and the work is not deemed to be complete untill the Development Team calls the work as meeting your Definition of Done. This is just unfinished work, and warrants nothing more than a conversation between a coder and a tester. Maybe the coder and tester pair untill the issue is resolved, that would be most effective, or they need to add a few tasks so things dont get forgotten. How they agree to do that is an issue for the Development Team and no-one should be telling them how to do that.
- Out of Sprint Bugs - Any problem that is identified in work that was previously marked as meeting the definition of done is considered an out-of-sprint bug. If the Development Team believe that the issue is small enough that it will not endanger their ability to meet their Sprint Goal then they should just fix it; Note it down and bring it up in the Sprint Retrospective so that The Scrum Team can figure out if their Definition of Done is sufficient. If however it will put the Sprint Goal in danger then it must be recorded and tracked as a bug. Do a root cause analysis and discuss at the Sprint Retrospective what you need to add to your Definition of Done to not have this sort of thing happen again.
The key parts to this are minimising documentation, bugs and root cause analysis, to only the times required. The Sprint Goal is the objective of the Development Team while maintaining quality with the Definition of Done. This provides the focus and transparency in the process that provides the Product Owner with working software, the Increment, at the end of the Sprint that meets their expectations.
Some Observations
We assign stories to developers in the Sprint Planning Meetings.
I would recommend against having Backlog Items assigned directly to Development Team members. Scrum (and Agile) works because we move from individual accountability to group, or team, accountability. This fosters self-organisation, and every time you hold an individual accountable for a piece of work you stop self-organisation dead in it's tracks.
Assign Backlog Items instead to the Product Owner, it is they who are accountable for the Backlog and everyone's understanding of it.
Developers start working on the sprint, and deliver features to QA for testing
This statement concerns me as it implies that you have either a separate QA Testing team or sub-teams inside of your Development Team. Since we can't have working software unless it is tested, test needs to be completed as part of the Development Team. Separate QA is waste if you have a professional Development Team that produces working software. It sounds like an organisational imposed condition is preventing you removing this impediment. This demonstrates a lack of commitment from management to your agile transformation as this is a fundamental, we'll understood and documented, issue that is a common starting point. Maybe they just have not made that change yet, but untill it does you will be unlikely to get the quality of software you should. You will also continue to incur significant rework.
QA finds issues in what was given for testing
The Development Team is accountable for creating done increments of working software. If QA find any issues then this is a serious breach of trust and I would hold the Development Team to account. If you are just starting down your road to agility then raise this issue at the Sprint Retrospective and brainstorm solutions.
If your quality is high enough then QA will no longer be able to justify their existence. They are product of poor software quality, and are not a feature of your future.
Now our group seems to be divided as to whether these issues fall in the category of Bugs. Creation of bugs seems to be the source of conflict.
My personal opinion is that these are bugs and depending on the criticality we can decide if these need to be picked up as part of the current sprint work or not.
Your personal opinion does not matter, the Development Team own this process and are the only one's that decide how the work is done. Hold them accountable for done increments of working software, stand back, and let them get on with it.
From my point of view a bug is traceable, while comments and test cases are not
Proper tooling can aliviate that. In most tracking systems, i use VSTS, comments and Test Cases are just as auditable as Backlog Items.
A bug also tells product that Stories may need to be more descriptive, and the product gets an idea about what it takes to get something done.
The opposite is true, only the lack of bugs tells the Development Team what it takes to get things done. The rest is Undone work which erodes trust with both Product Management and customers. You need a tighter Definition of Done.
The team says that raising bugs, for current feature development and including them in the current sprint changes the scope in the burndown charts, which for some reason may be bad.
If it's small, then just fix it. If it's big then it needs to go onto the Backlog and be ordered by the Product Owner. This is the only way the Product Owner can understand the u done work that is in the product.
So there is no question about Creation of Bugs for issues reported from "Live", those bugs will continue to be created.
These are very out-of-sprint bugs and I hope the full list of them, along with their root case, is assessed at the Sprint Retrospective and the Definition of Done enhanced accordingly.
