Hey Guys!
My team (fairly new team, fairly new SM) is flooded with bugs.
Its all happening within the sprint.
The QA team discovers the bugs while testing before going live with the new features .
And its never ending.
I know a few tactical steps to prevent or handle bugs (its hard to implement them though as the team feels they have every right to make mistakes its a human thing to do, so they don’t feel particularly pressured).
But i have only faint ideas how to handle that they are not closing the sprint saying we cant close until all the bugs are cleared.
We operate w 2 week sprints, this one has been running over 4 weeks now. Please help:) thx
Testing generate a lot of bugs and the sprint never ends, what can I do?
Share
There is many points in your question. A couple of ideas on how I would proceed. I would invite team to get focus (if not already in place) so you could at least complete 1 story. Ensure that bugs are handle following the Story priority so fix whatever is broken in your oldest story or higher rank before moving to other bugs. I would have team inspect the type of bugs if they were avoidable; Are they requirements understanding issue, is there use case not covered tought of before developping, etc. I found that using the “3 Amigos” or Story Kickoff so the BA, Dev, QA sits together to ensure they understand the story before starting it. It help see many angle and think of edge cases that can help during design etc.
A Sprint is a time box.
Anything that doesn’t meet the definition of done at the end of that time box goes back into the backlog. If it aligns with the next Sprint Goal (after the Sprint Review) then it might get pulled into the next Sprint.
“Done” should really mean “released into production so we get feedback”
Now, that’s going to make for a fair amount of discomfort, if the team is struggling, maybe even some conflict. It might be challenging and tough.
“Commitment, Focus, Openness, Respect, and Courage”
As a Scrum Master, you are going to have to walk the talk on these things, which means leaning into that discomfort, and asking in a positive way what’s one thing the team can work on and change to get closer to being able to deliver valuable, working software at least every Sprint.
Yes, we do have to allow for human error, but we can also work on things we can do to reduce the likelihood of an error happening in the first place. The practices that people tend to use here come from eXtreme Programming (XP).
How well do you and the team understand these practices?
Perhaps start there?