Can a development team deliver solutions with bugs?

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.

> - 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.

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.

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.

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.

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"

Hi Tim,

Would that be zero defects or zero detected defects?

Either way: Hat's off to you!

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.

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 done...as determined by a Definition of Done that is subject to continuous improvement.