Skip to main content

Can a development team deliver solutions with bugs?

Last post 05:19 am December 9, 2014 by Ian Mitchell
9 replies
07:41 pm November 18, 2014

We are having vibrant discussions around the question whether “a team can deliver solution with bugs” at the end of a sprint. General thinking is yes, because:

- DoD may (and usually does) define a quality bar that allows minor bugs
- Bug free software / solution is an oracle I have not yet found in the real-world
- It is up to the Product Owner to decide whether the solution increment is feasible

Would love to hear more views on this!

11:56 am November 19, 2014

Short answer Yes they can.

Ideal answer - Are they all proud of the work they put out? Why is there a mentality that some bugs are acceptable? Is the DoD in need of an update to ensure there are not bugs? Are bugs technical debt where the interest to fix them will only grow and grow? How do these bugs affect the end user of the product? How will that reflect in the adoption by the end user? How will that affect revenue & growth & ROI?

Example - you decide that you hire a painter to paint your bedroom in your house, you want each wall a different color and you agree that only 95% of where the colors meet each other need be straight - allowing for 5% mess in the corners where the paint meets. Is the room painted? Yes. Does it look like a shitty job has been done? Yes.

02:23 pm November 19, 2014

> - It is up to the Product Owner to decide whether the solution increment is feasible 

That's the key consideration.

Defects may be added to the Product Backlog for planning into a future Sprint. They effectively amount to undone work.

02:53 pm November 19, 2014

Bug free software for complex systems does not exist. We all should realize this. If the known bugs are easy to fix, just do it. The key question is: does the software deliver value for the customer and the company? And second: as a customer, I will walk away from companies releasing buggy products.

07:54 am November 20, 2014

Couldn't agree more with the previous comments.

A team should strive to ship increments with zero identified defect, organizing itself delivering so, even if it costs a bit of extra time. Technical debt always exists, sure: just do not let it grow knowingly and the bad habit of giving bugs a free pass set in.

03:23 pm December 3, 2014

Short answer: NO if they plan it!
i mean how can a DoD allow some "minor" bugs? the ideal status is to release an increment which is really done. So if the DoD allows some bugs, that menas it is definitely a DoD which needs to be reviewed.
A Scrum team should aim to release increments which are free of bugs. As a SM i would recommend by PO and dev. team to review the DoD in such a case.

03:21 pm December 4, 2014

Hi Christiaan, I have to respectfully disagree with you. I have seen it done in an organization with 20+ scrum teams, with a policy of zero defects - and the policy was adhered to. Zero defects. It was a thing of beauty.

"Those that say they can't and those that say they can are both right"

04:28 pm December 4, 2014

Hi Tim,

Would that be zero defects or zero detected defects?

Either way: Hat's off to you!

09:03 am December 6, 2014

I have to agree with Christiaan because complex systems will have defects. Tim's zero-defect goal can be achieved, but with larger team, de-scopping and heavy testing. If the PO can't afford that, the reality is what Christiaan said.

05:19 am December 9, 2014

In Scrum terms "zero defects" means that there is no undone work remaining, and the Product Backlog is therefore empty.

We should note however that the Scrum Guide doesn't talk about defects at all, probably because the term isn't all that helpful. There is simply work that has been done and work which remains to be determined by a Definition of Done that is subject to continuous improvement.

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

Please note that the first and last name from your 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. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, 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 may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.