Skip to main content

Question regarding defects

Last post 02:50 pm July 16, 2018 by Manjunatha Ramappa Yerdummi
3 replies
02:01 pm June 28, 2018

Hi all.  I have a quick question regarding how a situation should be handed regarding defects.  Lets say the team has commited for a sprint to develop the feature X, and the criteria of the definition of done must be that the developement have no defects.

At the end of the sprint the development was completed, and the feature has been tested in the test environment with no issues. The PO decides to release the feature X to production and then one week later, the end users report some errors.

The feature X user story was already marked as "done" so my questions are:

1. A new story has to be created to handle the defect?

2. or .. we use the same user story for the feature X and move it back to the back log?

3. I assume if its critical, the team must include it in the current sprint backlog and handle it right away, if not critical, then it can be incluided in the next sprint?  Is this assumption correct?

Thanks in advance


05:14 pm June 28, 2018

Ad 1. I would advise to make a new PBI.

Ad 3. I would agree with your assumptions.


05:34 pm June 28, 2018

A user story is a placeholder for a conversation about a possible requirement. Once the work is understood to be complete then the conversation ends, and the story is retired. New conversations in subsequent Sprints, even if they relate to the same old requirement, imply a new story to represent them.

I put together a blog post on this topic in October:

https://www.scrum.org/resources/blog/zombie-stories-conversations-beyond-grave


04:25 pm June 30, 2018

Firstly, this scenario is assumtion only; apart its not advised to have exhustive set of tests for a given feature to ensure 0 defects, which in reality is impossible. So DOD(Defination of Done) of this kind should never be set.

Ideally, DOD should ensure the release should be free of Priority 1 and Priority 2 bugs(impact of bug on the system).

    Now, how to handle the Customer bugs(Fault Report / Tickets)/ Internal fault reports.

--------------------------------------------------------------------------------------------------------------------

There are 2 major events which occurs at the begnning  of each sprint life cycle.

1) Phase 1  Meeting- User Stories(items) Planning phase-1 meeting, for estimation( user stories are commited in phase 1).This phase includes multiple teams for a given project.

2) Phase 2 Meeting - Deriving tasks and sub-tasks for Commited user stories, furthermore a buffer time (free man hours) should be provisioned for each and every team in order to address tasks entering middle of the sprint.

Ex: Bug fix with very high priority, which demands deviation from planned tasks/activities.

what is buffer time in project management http://www.velaction.com/buffer-time/

------------------------------------------------------------------------------------------------------------------------

When should be a Fault report / bug should be considered as New User Story.

After a fault report analysis is done and effort estimation is quoted, its time to check if the fault correction can fit into current sprint or else it should be taken in the upcoming sprint.

If the effort required for the fix is considerably high, a new user story should be created for the same and its has to be a potential cadidate for sprint planning phase 1(Next sprint life cycle ofcourse).

-------------------------------------------------------------------------------------------------------------------------

Every Battle is won before its fought !!! ~Sun Tzu


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.