Du sprichst da ein wichtiges Problem an; ich schätze die Quote liegt gerade am Anfang tritt es bei mindestens bei 50% der Teams auf. Allerdings muss man sehr vorsichtig sein, wie man dieses Problem addressiert. Die von Dir vorgeschlagene Lösung funktioniert zwar, hat aber zwei sehr gewichtige Nachteile:

1. Man kann die statistischen Verfahren nicht mehr einsetzen, weil sich dann der Mittelwert der Velocity immer weiter nach unten verschiebt. Man kappt sozusagen die Rückkopplungsschleife und muss mit “gutem Gewissen” arbeiten. Das ist zwar kein Ausschlusskriterium für diese Lösung, aber aus meiner Sicht ein gewichtiger Nachteil
2. Das Team wird dadurch zu einem gewissen Teil entmündigt. Wer immer die Entscheidung trifft, so zu arbeiten, unterstellt dem Team, dass es von sich aus nicht in der Lage ist, unter Druck qualitativ saubere Software zu liefern. Die Diagnose mag richtig ober falsch sein, die Reaktion erschwert aber die Selbstorganisation eher, als dass sie dieses grundsätzliche Problem angehen würde. Aufgrund dieser Überlegung würde ich Deinen Vorschlag als Dauerlösung nicht empfehlen, höchstens als Interimslösung, um Zeit zu gewinnen, das eigentliche Problem anzugehen.

Ich sehe noch mindestens zwei Alternativen, die meines Erachtens nicht so stark in das Selbstbestimmungsrecht des Teams eingreifen.

Zum einen könnte man das Planungsverfahren um eine weitere Kanbantechnik erweitern. Tritt das von Dir beschriebene Problem auf, so führt das ja meistens dazu, dass neue Funktionalität sehr schnell entwickelt werden, aber lange im anschließenden manuellen explorativen Test hängen, weil immer wieder neue Fehler entdeckt werden. Das führt dazu, dass sich “realisierte” Karten vor oder im Test stauen. Nun kann man gemäß Kanban die maximale Länge dieser Warteschlange begrenzen, z.B. auf 10 oder 20 Punkte. Ist die Warteschlange so weit gefüllt, werden keine neuen Features mehr angefangen, sondern nur noch Fehler behoben und Designschulden abgetragen. Das senkt auch automatisch die Velocity und ist daher ein selbstregulierendes System. Allerdings springt es natürlich nur auf Schlampereien an, die unmittelbar zu mehr Fehlern führen, nicht auf langfristige Designprobleme.

Alternativ (oder ergänzend) könnte man auch das Team in dieses Problem hineinlaufen lassen und versuchen, die Folgen durch andere Metriken transparent zu machen, wie Durchlaufzeit pro Feature (zu lang wegen Fehlern), Designmetriken etc. Das würde dem Umstand Rechnung tragen, dass hier möglicherweise zu einseitig auf die Velocity gestarrt wird und eine “Metrikverzerrung” stattgefunden hat: Die Metrik hat die Realität angepasst, nicht umgekehrt. Aber auch dieser Ansatz ist zweischneidig, weil man den Teufel (Metrikverzerrung) mit dem Belzebub (noch mehr Metriken) austreibt. Also auch das nur eine Übergangslösung, zumal Designmetriken mehr als fragwürdig sind.

Es bleibt der Versuch einer Ursachenanalyse (Root Cause Analysis), um das eigentliche Problem hinter dem Verhalten des Teams zu finden und zu beheben. Das wird erfahrungsgemäß kaum auf Anhieb klappen, deshalb kommt man meistens um die Teillösungen nicht drum rum. Aber ich denke, hier lohnt sich Geduld.

Eine Anmerkung zum aktuellen Artikel. Du schreibst “…dass man sich auch für den Fall rüsten sollte, dass man deutlich mehr schafft, also ruhig für 42 Punkte Features aufnehmen…”
Ich denke man muss da je nach Team sehr vorsichtig sein. Manche Teams reagieren auf eine zu volle Featurschlange mit Beschleunigung durch schlechtere Qualität. Bei solchen Teams - wieviele sind das? - darf man nicht mehr verplanen als man *guten Gewissens* versprechen kann. Slack benutzt man dann am besten zum Abzahlen der technischen Schulden. Hat man auch dann immer noch Zeit, kann man ja nachplanen, d.h. in Absprache mit dem Kunden neue Stories nachschieben.