Skip to main content

How SM should handle the conflict between Dev and QA?

Last post 02:18 pm September 10, 2019 by Mike Miller
4 replies
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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.