Known issues in an application

Scrum allows it up to a point, because the principle is to deliver early and often rather than to wait for perfection.

Here's the sense in which it is acceptable: If the Product Owner makes the decision, then you must ask if he has effectively renegotiated the User Story and/or its Acceptance Criteria during the sprint. If that is the case then the story can be revised and completed as normal.

However, if this is not the case, then technical debt will be incurred and it will need remedy before it becomes too expensive to pay off. Any compromising of the Definition of Done is likely to incur technical debt...regardless of whether or not the PO gives his approval.

I'd argue that Scrum doesn't allow technical debt to be incurred, though it is understood that it does happen. This is one of the reasons why Definitions of Done need challenging and improving (e.g. in Retrospectives).

Does the scrum theory allow that an increment contains known issues?

Yes, though it doesn't encourage known issues either. Scrum does not require that the increment be perfect, only that it be useable and potentially releasable.

Is this a product owner decision (balancing value & risk) or a Development Team decision (quality guidelines & DoD)?

Scrum does not speak specifically to this point. So, IMO, and staying true to the Scrum framework/principles, the PO decides whether and when the increment is released, and orders the product backlog. As such, the decision to release with a known issue is made by the PO. In addition, and also IMO, the dev team can fix the known issue any time they want, though they should make this decision and work highly visible. For more on that view, see the Dev Team Improvement Backlog here:
http://www.scrumcrazy.com/Scrum+Strategy+-+The+Dev+Team+Improvement+Bac…

I'd argue that Scrum doesn't allow technical debt to be incurred

I'd argue that Scrum doesn't say anything about technical debt, other than the increment must be useable and potentially releasable, both of which are subjective opinions of the PO and users/stakeholders.

I'd say it's rather easy to be doing Scrum correctly and incur a lot of technical debt. I'd also say that it's rather easy to be doing Scrum correctly and incur very little technical debt. Scrum specifically provides the DoD to help prevent technical debt, but the team can certainly create an unhealthy DoD that allows for loads of technical debt.

Scrum doesn't really speak a lot on technical practices.

Hi Charles

> I'd argue that Scrum doesn't allow technical debt to be incurred
...
> Scrum doesn't really speak a lot on technical practices.

Yes you are right. I was thinking of the Scrum Primer (the de facto Scrum Alliance position) which is somewhat more critical than the Scrum Guide, referring to technical debt as "undone work".

I agree with Charles and would also like to add that technical debt can be perfectly acceptable when e.g. trying to meet a deadline. Just make it highly visible and pay it back as soon as possible.

the Scrum Primer (the de facto Scrum Alliance position)

I think the Agile Atlas is the new de facto Scrum Alliance position:

Agile Atlas link: http://agileatlas.org/ (See "Core Scrum", which is their equivalent of The Scrum Guide)

One point of interesting note -- the agile atlas view of Scrum from the Scrum Alliance has "come around" to be much closer to the Scrum Guide, including incorporating things like "forecast" instead of "commit", etc., "The Development Team" instead of "The Team", etc.

referring to technical debt as "undone work".

The "Undone Work" pattern is also still the recommended practice(when the bad practice of undone work exists!) for Scrum.org. We use it in our PSM class. The term "Undone Work" was described in a previous Scrum Guide optional strategy. In 2011, the "Undone Work" strategy was removed from the Scrum Guide. The removal of "Undone work" is briefly alluded to here:

<snip from: https://www.scrum.org/About/All-Articles/articleType/ArticleView/articl… >

"...Unfortunately, some organizations use releases to compensate for bad development practices. A usableIncrement is one with no “undone” work associated with it at the end of a Sprint. If teams are unable to create truly usable Increments, the remaining work (testing, documentation, user acceptance, etc.) are done as part of the release process - sometimes referred to as the stabilization phase. In this case, the release plan codifies the acceptance of the poor development practices, and makes it incredibly difficult for a Product Owner to effectively plan when a release will happen...."
</snip>

You can access and read about the Undone Work pattern in the 2010 Scrum Guide here:
http://www.scrumcrazy.com/2010+Scrum+Guide

technical debt can be perfectly acceptable when e.g. trying to meet a deadline. Just make it highly visible and pay it back as soon as possible.

This is "perfectly acceptable" so long as it is not repeated often, and so long as the debt is payed back quickly. Often times, though, it becomes a really bad habit and is repeated often, and never paid back. Watch out for non Scrum Team members who pressure the Development Team to repeatedly do the Undone Work thing -- it can very easily become a dysfunction that leads to massive technical debt.

Watch out for non Scrum Team members who pressure the Development Team

(I've also seen Dev Teams do this to themselves, to meet perceived "important deadlines")

I don't think there is anything called "Known Issues" in Scrum. They are just missing features and are of low priority for PO.

Whenever a PO accepts a user story with so called "known issues" it means he is agreeing that the product can be released without those features.

I would agree Sanjay.

SCRUM does not have anything called known issues as increment. These are nothing but technical debts. I think it would be team highlighting the problem and PO approving to get this done ASAP not delaying any further to spill onto upcoming sprints.

Hi guys.

So whether a known issue is allowable or not should be decided on a case by case basis by the product owner and team dependent on whether it is an issue of technical or user focussed quality.

In simple terms, within Scrum. The Product Owner is trusted to know what is acceptable for the business and user. The dev team are trusted to know what is acceptable from a technical perspective. Therefore although Scrum encourages quality delivered after each sprint, if there are any remaining issues it is up to the Product Owner to decide if the business and user should live with it and the product is still shippable. It is up to the dev team to decide if the product is technically still shippable. Also any issues are seen as an impediment to be dealt with later (as soon as possible)

Of course as you know this is not the ideal situation and we should strive for perfection :)