Skip to main content

How to treat missing requirements

Last post 06:06 am November 15, 2019 by Ian Mitchell
3 replies
01:56 pm November 14, 2019

Hello, I  would like to know what is the right way to handle the following scenario. Let's say we are working in a BPI and we move that ticket into QA status. At that moment the QA detects a missing requirement in the initial specification of the ticket. how we should handle this case according to Scrum?



A- Create a bug in order to report that was a missing requirement in the initial specification

B- Create another ticket to meet that requirement

C- other options

I was wondering is will be accurate to create a bug for something that for me wasn't a development bug.

Thanks!


06:44 pm November 14, 2019

@Yassiel Oliva, Do what is necessary to make the situation transparent and to get the work to a "Done" state.


07:06 pm November 14, 2019

I know you're asking for some instruction on which option is best to take and what do next, and I will provide you suggestions...but first remember that's not exactly Scrum. Those decisions/changes will come from the Scrum Team through Inspect and Adapt.

Scrum doesn't outline how to handle this specifically because Scrum is a framework for your processes, and Scrum will help you identify problems within the existing processes and put the responsibility of making those improvements onto the Scrum Team.

Now for the suggestions...

The Sprint has helped you identify there is a process gap somewhere. Retrospectives give the team opportunities to solve their own problems and experiment with solutions. Some questions to consider asking:

  • How did this situation get identified?
  • Why so late in the process/workflow?
  • What action can we take next sprint to improve and prevent situations like this?
  • If this does happen again, how do you (the Dev team) want to handle this?
  • Should the Working Agreement be updated for this change? 

I recommend first creating the bug and then assess the current Story.

  • As a customer/stakeholder of the team, should this functionality and Sprint Goal be demoed to me and called complete?
  • If no, then it's a good idea to resolve this bug in current Sprint. I don't see the need to create a separate story in addition to this bug.
  • Can the Story be considered "Done" based on existing Definition of Done?
  • Should the DoD be updated because team realizes this work should not be called "Done"?

Any issue preventing work to be called "Done" is a development bug, even if the resolution of it doesn't go directly to a developer. The team needs to be cross-functional and so the resolution shouldn't be dependent on someone who isn't a part of the team. If they do, and especially often, then the structure of the team should be assessed by the Scrum Team.


06:06 am November 15, 2019

the QA detects a missing requirement in the initial specification of the ticket. how we should handle this case according to Scrum?

Does the team consider the requirement to be essential to the Sprint Goal? .find_in_page{background-color:#ffff00 !important;padding:0px;margin:0px;overflow:visible !important;}.findysel{background-color:#ff9632 !important;padding:0px;margin:0px;overflow:visible !important;}


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.