Fehler und Stories im Product Backlog?

Fehler und Stories
Von Sebastian Schneider // 10.02.2018 // 0 Kommentare

​Fehler passieren und sind menschlich. Wenig überraschend werden Sie mit der Frage gehören Fehler und Stories eigentlich gemeinsam in ein Product Backlog konfrontiert. Dieser Frage wollen wir uns in diesem Artikel einmal genauer widmen und klären, warum Fehler eigentlich wie Anforderungen zu behandeln sind.

​Grundlagen: Fehler und Stories

​Was ist ein Fehler?

​Ich möchte hier keine wissenschaftliche Definition eines Fehler angehen. Sondern nur soweit festhalten, dass ein Fehler eine Abweichung von einem gewünschten Verhalten ist. Eine vorhandene Forderungen wird nicht so erfüllt, wie wir sie gerne hätten und das bezeichnen wir an dieser Stelle dann als einen Fehler.

Was sind Anforderungen?

​Auch wenn es nach Scrum kein Muss ist, so sind doch die meisten Anforderungen die Benutzer an ein System haben in User Stories festgehalten. User Stories beschreiben Anforderungen an ein System aus Anwendersicht in einem sehr einfach verständlichen Aufbau.

In Scrum sind die Anforderungen immer im Product Backlog, das wissen Sie, wenn Sie regelmäßig hier die Artikel auf dem Blog lesen. Die Anforderungen sind als Product Backlog Items vorhanden und müssen dann durch das Refinement auf eine Reife gebracht werden. Dann kann das Entwicklungsteam diese ​Anforderungen ​in der Sprint Planung auch bearbeiten und planen.

​Da gehören Fehler hin

​Kunde meldet Fehler nach Auslieferung

​Im Grunde sind Fehler nichts weiteres als Anforderungen! Wenn Sie etwas an den Kunden ausgeliefert haben und er der Meinung ist, es gibt einen Fehler, dann muss dieser Fehler priorisiert werden. Damit ​bekommt er eine eindeutige Reihenfolge mit der restlichen Arbeit! Also ab damit ins Product Backlog!

Der Product Owner ist derjenige, der diesen Fehler dann (ggf. in Absprache mit dem Kunden) wieder priorisiert und für den nächsten oder einen späteren Sprint ​von ​dem Entwicklungsteam ziehen lassen kann.

​Fehler, die im Sprint auftreten

​Wenn Fehler im Sprint auftreten, dann halte ich es ganz gerne so, dass diese nicht in das Product Backlog kommen, wohl aber in das Sprint Backlog. Denn diese Fehler gehören direkt zu einem Product Backlog Item, dass Sie gerade bearbeiten. Es ist solange nicht "fertig", bis eben alles fertig ist, damit das Product Backlog Item ​nach der Definition of Done als fertig gelten kann. Wenn Sie die Stories im Sprint priorisiert haben, dann kann ein Fehler somit auch klar einem Product Backlog Item zugeordnet werden und damit wird dann auch sofort die Priorität sichtbar.

Ein Fehler ​kann eine Unterbrechung im Sprint ​darstellen und damit gibt es unterschiedliche Möglichkeiten, wie Sie darauf reagieren können. Als Empfehlung gilt -  egal welche Lösung Sie bevorzugen - dass der Fehler direkt im Sprint behandelt wird.

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt.

Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben.

Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen.

Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

>