Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.
Start your free trial
brianruscio
13,235 PointsHow are "Bugs" found during QA testing factored into Backlog Refinement and Sprint Planning? Which has priority?
As bugs are discovered during testing, do they become part of the backlog and thus brought into sprint planning?
2 Answers
Matt Anthes-Washburn
Treehouse Guest TeacherAmanda, your answer is great, and the examples really illustrate your point. As bugs come up in testing, the first question is whether they relate to in-sprint stories or other things outside the sprint. If it's in-sprint, the issue should be resolved before the story is considered "Done" by the team and the Product Owner. If it's out of the current sprint, a new Product Backlog Item is created and it is prioritized against the rest of the Product Backlog.
This is often a fine line that the team needs to negotiate together, but being clear on this dividing line helps to avoid scope creep and unintentionally putting the current sprint and the current stories in jeopardy.
Do these answers help?
Jeff Pierce
18,077 PointsAnurag Prakash of American Express, wrote a blog post on Scrum Alliance titled "Dealing with Bugs in the Product Backlog": https://www.scrumalliance.org/community/articles/2013/october/dealing-with-bugs-in-the-product-backlog
"Bugs are similar to a story in many respects. They can also be considered as a story to implement correct functionality, given the current state of incorrect functionality."
Amanda Flagg
1,716 PointsAmanda Flagg
1,716 PointsI can't speak for every scrum team, but as a member of one (in the QA dept), we handle bugs found that relate to the current sprint by fixing them in that same sprint.
The exception to that would be a bug found that lies outside of the scope of changes covered in the current sprint. In that case, you are more likely to have found a bug that pre-dates the current sprint work, which would then be considered for placement into the backlog.
Example:
You are testing a calendar app. The current sprint work consists of modifying functionality to the add/edit portion of calendar items. You find a bug that prevents the user from editing a calendar item. This would require an immediate fix within the current sprint.
During the same testing, you discover a bug with notifications not being triggered for a calendar item. This is not within the scope of change for the add/edit functionality. This would be placed into the backlog for prioritization, and possible inclusion into the next sprint during planning.