Von der (Un)Möglichkeit eines Teilzeit-PO - Teil 2: Was passiert, wenn der PO trotzdem nicht Vollzeit da ist.

In Teil 1 ging es darum sich bewusst zu machen, mit wie vielen wichtigen Aufgaben ein PO seine Zeit verbringen kann, um das Team und damit das Produkt produktiver und erfolgreicher zu machen. Aber natürlich gibt es Gründe, Situationen und Umstände, wieso (noch) kein Vollzeit-PO die Rolle besetzen kann. Die finanziellen Mittel fehlen, die geeigneten Personen sind schwer zu finden, oder es gibt alte Zuständigkeiten oder andere Projekte, die die Aufmerksamkeit des POs fordern.
Die fehlende Zeit geht dann meist direkt zu Lasten des Backlogs. Nach der DEEP-Regel sollte ein Backlog „Detailed appropriately, Estimated, Emergent, and Prioritized“ sein. Auf alle diese Aspekte hat die fehlende Zeit Einfluss:
Detailled appropriately: Die Detaillierung, die notwendigen Zusatzinfomationen und Akzeptanzkriterien gehen meist verloren. Stories werden unzureichend beschrieben in den Sprint gekippt und es liegt dann am Team, was und wie viel gemacht wird. Denn für Rückfragen steht der PO als Teilzeitkraft ja auch nicht immer zur Verfügung.
Estimated: Im schlechtesten Fall werden Stories erst im Planning „mal schnell“ geschätzt, damit man wenigstens ein paar Punkte für die Velocity hat. Die Möglichkeit des POs, Komplexität und Aufwand einer Story mit in die Priorisierung einfließen zu lassen, oder sich einfachere, mehr oder weniger gleichwertige Lösungen einfallen zu lassen, geht verloren.
Emergent: Dass ein Backlog wächst, lässt sich in einer aktiven Umgebung kaum verhindern. Je weniger Zeit ein PO hat, umso größer ist jedoch die Gefahr, dass das Backlog Schlagseite bekommt und einzelne Usergruppen oder Stakeholder überrepräsentiert sind – einfach, weil sie immer am lautesten schreien oder den besten oder mächtigsten Draht zum PO haben. Bei einem Produkt wie z.B. einem Webshop kann es leicht passieren, dass der Großteil der Entwicklung auf das Backend und die Abwicklung geht. Die User in den User Stories sind meist die eigenen Kollegen, während die Kunden draußen in der Welt relativ kurz kommen. Sie stehen dem PO eben nicht auf den Füßen, der in seiner knappen Zeit nur zum Abarbeiten der Kollegenwünsche, nicht aber zum Reflektieren und Analysieren kommt.
Prioritized: Der Unterschied zwischen einer (beliebigen) Reihenfolge und einer Priorität sollte gemeinhin bekannt sein. In einem wenig gepflegten Backlog kann diese Grenze jedoch unscharf sein. Sei es, weil die Stories ungenau geschätzt sind, weil der PO ihre Hintergründe und damit Wichtigkeit nicht mehr genau auf dem Schirm hat, oder weil er schlicht und einfach den Überblick verloren hat und über wenig Zeit verfügt, ihn wieder zu gewinnen. Ein guter PO kennt sein Backlog quasi auswendig und kann schnell sagen, welche Stories hinten herunterfallen oder sich verschieben, wenn jemand mit einer neuen, total wichtigen Idee um die Ecke kommt. Hat er zu wenig Zeit, sich in seinem Backlog wirklich auszukennen, kann er sie nur beliebig einsortieren und darauf hoffen, nicht aus Versehen etwas Wichtigeres vertagt zu haben.
Hopfen und Malz also verloren? Nun, man kann aus jeder suboptimalen Situation noch das Beste herausholen. Dazu bald mehr...
Teil 3: Wie man das Beste draus macht.
Teil 4: Was dann immer noch fehlt.