Forums

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. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

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.

'minor' bugs at the end of a Sprint
Last Post 02 Jun 2014 04:00 AM by Bryan Woodlief. 3 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages Not Resolved
Bryan Woodlief
New Member
New Member
Posts:2
Bryan Woodlief

--
01 Jun 2014 12:33 PM
    Is it acceptable within SCRUM to have ‘minor’ known bugs for any reason at the end of a Sprint and the Definition of Done still be met?
    For example can the Scrum Team’s definition of “Done” state that minor defects can be reviewed and placed on the Product Backlog to be addressed in a future Sprint?
    Ludwig Harsch
    Basic Member
    Basic Member
    Posts:272
    Ludwig Harsch

    --
    01 Jun 2014 10:50 PM
    Yes, it can.
    As long as the Product Owner prioritizes them and states they are acceptable for productive use, you can proceed like this. If this becomes a major problem, you may want to inspect the root cause of these bugs and improve your process.
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1575
    Ian Mitchell

    --
    02 Jun 2014 02:56 AM
    Suppose a Development Team discover that system performance deteriorates significantly with more than 50 concurrent users, and grinds to a halt with 100. They are unable to rectify the matter before the end of the Sprint, and the PO is informed accordingly.

    He or she might choose to accept this defective increment anyhow, with a view to releasing it to a group of 20 early adopters. The new features in the increment may thus be evaluated without adverse incident, and the ROI of the product can be potentially improved. Clearly if the PO refused to accept the increment altogether, then such opportunity would be lost.

    This means that it is indeed "acceptable" to have bugs at the end of the Sprint - even serious ones - because the PO might still value the increment. The PO is ultimately responsible for ROI and the decision to accept a delivery, and whether or not to release it in some form, should be made on that basis.

    What would *not* be acceptable in Scrum would be a failure to inspect and adapt the team process, so that similar defects can be pre-empted in future, and the incurral of technical debt avoided. In the above example this could involve modifying the Definition of Done so that appropriate load testing is performed.
    Bryan Woodlief
    New Member
    New Member
    Posts:2
    Bryan Woodlief

    --
    02 Jun 2014 04:00 AM
    That is what I assumed but wanted to be sure.
    Sincerely, Thank you for the feedback!
    You are not authorized to post a reply.


    Feedback