Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.
Sign up to join this community
I want to keep track of all the regression bugs in JIRA, which is not related to any specific user stories in the current sprint. While creating as separate bug/task in the sprint affect its scope.
I'd suggest you look at it as two separate actions:
For the first one, I see no reason not to. I think Jira has a "bug" issue type by default and these are perfectly valid items to have in your backlog. If you want something more specific, you can always create a new issue type specifically for this kind of bug.
As for bringing it into the sprint, this should normally be a conversation between the product owner and team. Most mature Scrum Teams have an overarching sprint goal like "Users will be able to pull a report of their data usage over the past 6 months" and the team can speak to if pulling in the bug puts the goal at risk while the product owner can speak to the relative priority of the bug. Even if your team isn't quite to the point of having these clean goals to talk around, they can speak to what work might not get done if they bring the bug in.
The Scrum Guide states that during the sprint "No changes are made that would endanger the Sprint Goal". Many people take this further and say that no work should be introduced at all. That's not strictly true. In fact, the Scrum Guide also says: "Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned." However, if your team is completely new to Scrum or not yet disciplined in managing incoming work, it may be safer to say that all those bugs wait until the next sprint.
What you can do is, you can create a task in JIRA (Ex: Regression Testing Sprint - 05) and the bugs which you encountered during the Regression Testing, you can link those encountered bugs with this regression task(Regression Testing Sprint - 05) which will help you to keep the track of those bugs. If you add those bugs in the current sprint, it will affect the sprint and the Product owner can decide that he/she need that bug to be resolved in the current sprint or not. If he/she wants that bug to be resolved in the current sprint then it will affect the current timeline of the current sprint OR else you need to remove some added task from the current sprint to make sure that timeline of the current sprint doesn't get affected by resolving the bug encountered during the regression.
There is one more approach that is followed in quality assurance services: You can create an EPIC for the generic issues related that sprint on Kanban Board in JIRA and you can link current sprint to it.
This way all the generic issues will be shown up cumulatively under a single EPIC link and can be referred/ worked on as per the priority. Further, Kanban allows us the flexibility to shift the exists tasks to next sprint. So, the same EPIC could be even moved to following sprint as well. By using this approach, it will be separated from the remaining tasks/ tickets as well.
