Fehler und Stories im Product Backlog?

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

Leave a Reply 0 comments

Leave a Reply:







>