How SM should handle the conflict between Dev and QA?

Last post 02:18 pm September 10, 2019
by Mike Miller
4 replies
Author
Messages
06:36 pm September 7, 2019

Scenario - 

We are approaching end of the sprint. QA guy logged the bug related to some functionality. Dev guy is saying he wont be able to fix it in the current sprint. He will fix it in next sprint.

Here, QA is saying he will not Sign Off until that bug is fixed.

How SM should handle this situation? 

06:55 pm September 7, 2019

What does the Product Owner say?

The role of the Development Team is to produce a potentially releasable Increment at the end of every Sprint. If this bug remains, would the Increment be potentially releasable? Can the changes that introduced the bug be reverted to ensure that other work that is done can be included in a potentially releasable Increment? The Product Owner needs to be involved in these discussions to understand the options and the risks or benefits of each option. The Scrum Master can facilitate these discussions, as needed.

07:48 am September 8, 2019

What does the Definition of Done say in this scenario?
But looking into the future, the better question for the SM to ask the team is: how can we prevent this scenario in the future ?!?!?

01:46 pm September 8, 2019

I speak as a former Programmer and QA, myself.

But, as I'm sure you already appreciate, a Scrum Team has only 3 Roles: SM, PO and Dev? And the "Team" is responsible for the quality of the increment, not just one individual?

So sounds like there might be need for a gentle, little bit of coaching - i.e. "reminding" people?

But what might be the standard Scrum Tools (events and artefacts) the Team could use:

  1. to examine what went wrong in this instance?
  2. to prevent a recurrence in the next Sprint? (Maybe bring more transparency to the on-going situation by conducting more frequent inspections during the Sprint?)

 

 

02:18 pm September 10, 2019

 

  1. On a Scrum Team, both the "QA guy" and the "Dev guy" are Developers. There should not be any specialty designation.
  2. Generally, I would recommend NOT logging "bugs" for Items that are part of the current Sprint Goal, especially if the "bug" is something that should have been addressed per the Acceptance Criteria of that Item and/or the Definition of Done for all Items. The Item can simply be considered incomplete, and a conversation between the two team members (instead of logging a "bug") should suffice in resolving that Sprint Goal Item.
  3. Alternatively, or if there is ambiguity, such an edge case "bug", I would recommend that the Development Team and Product Owner quickly discuss the scope of the original Sprint Goal Item. If it is out of scope for the Sprint Goal Item, only then would I recommend logging the "bug" into the Product Backlog which can then be refined and prioritized to be worked on in a future Sprint.

As an observation from your post, I'm making an assumption that there may be an adversarial type relationship in your team's design or culture that should be squashed. TEAM over INDIVIDUALS.