Backlog bei Auftragsprogrammierung

Folgende Situation tauchte bei einem unserer Kunden auf:

Im Backlog hingen zum Teil Stories, die, bevor sie in einen Sprint hineingezogen werden können, erst noch beauftragt werden müssen. Im gleichen Backlog hingen Stories, die sofort in einen Sprint kommen durften.

Das hört sich erst einmal trivial an, aber es war für das Team und den Product Owner schwierig den Überblick über Anfrage/Angebot/Beauftragt zu erhalten.

Das Team ist dann sehr schnell auf eine ganz einfache Lösung gekommen. Es gibt jetzt drei Backlogs oder besser Backlog-Stufen.

In die erste Stufe "Anfrage" hängt der Product Owner neue Stories hinein, nachdem er eine Idee davon hat, was der Kunde möchte. Das Team pokert selbständig schon mal eine grobe Abschätzung aus.

Bei dem nächsten Backlog-Meeting steht der Product Owner für genauere Fragen zur Verfügung. Im Anschluss erzeugt das Team die Tasks und pokert sie auch gleich aus.

Darauf hin ist der Product Owner in der Lage ein konkretes Angebot an seinen Kunden zu stellen und hängt die Story in die zweite Stufe "angeboten" um.

Sobald der Kunde beauftragt hat, wird die Story dann in die dritte Stufe, dem eigentlichen Backlog umgehangen und mit einer Priorität versehen. Ab diesem Moment kann die Story in einen Sprint hineingezogen werden.

Die Idee dazu, ist vom Team selbst gekommen und es hat sofort funktioniert. Ein guter Nebeneffekt war auch, dass jetzt alle (auch die Stakeholder, die mal zum Sprint-Review vorbeikommen) einen guten Überblick über den Angebots/Auftrags-Status der verschiedenen Projekte haben.