Oliver und Tim sprechen in dieser Folge über ein Problem, das
vermutlich viele Product Owner kennen: Das Team arbeitet dauernd an
Stories, die gar nicht wichtig sind. Der Anlass ist ein
Coachingfall. Ein Produktmensch klagt darüber, kaum voranzukommen.
Sein Team hat immer zu viel zu tun. Gleichzeitig schreiben die
Teammitglieder eigene Tickets ins Backlog. Oder sie ziehen sich
Themen selbst von irgendeiner Stelle des Backlog. Manche Stories
laufen auch gerne über mehrere Sprints weiter, ohne dass die
Developer ein Störgefühl zeigen. Nur passt das selten zur
eigentlich notwendigen Produktstrategie des Product Owners bzw. der
Produktorganisation. Wenn Teammitglieder selbst Einträge für das
Product Backlog schreiben, ist das natürlich erstmal ein absolut
gutes Zeichen. Es zeigt echte Selbstorganisation. Schwierig wird es
dort, wo diese Einträge ohne Absprache direkt ins Backlog wandern
und die Reihenfolge verändern. Genau diese Reihenfolge liegt
eigentlich in der Verantwortung der Produktverantwortlichen. Fehlen
klare Working Agreements, wer Tickets erstellt und wer sie
freigibt, entsteht schnell Unordnung im Backlog. Stories, die gar
nicht wichtig sind, bleiben oft über mehrere Sprints liegen. Man
möchte begonnene Arbeit ja zu Ende bringen… Das klingt
vordergründig vernünftig, kostet aber Steuerungsmöglichkeit. Ein
hilfreicher Reflex: Unfertige Einträge wandern konsequent zurück
ins Product Backlog. So bleibt die Priorisierung nach Wert
erhalten. Die Produktverantwortliche soll dann jederzeit neu
entscheiden können, welche Themen gerade wichtiger sind. Hinter dem
Punkt "Stories die gar nicht wichtig sind" stecken oft andere
Gründe. Häufig fehlt eine klare Produktvision. Technisch geprägte
Teams setzen dann eigene (ggf. technische) Prioritäten, weil
niemand ihnen die Richtung von oben deutlich genug vermittelt hat.
Aber auch andersrum mag technische Komplexität eine Rolle spielen:
manche Produktverantwortliche durchdringen die technischen
Zusammenhänge nicht gut genug bzw. schaffen es nicht, die
fachlichen Zusammenhänge und Notwendigkeiten dem Team gut genug zu
vermitteln. Entwicklerinnen und Entwickler treffen dann lieber
eigene, technisch motivierte Entscheidungen - schlichtweg weil
ihnen der Kontext fehlt. Fehlt zusätzlich eine Scrum Masterin bzw.
Agile Coach moderiert oft niemand die nötigen Retrospektiven. Genau
dort sollten solche Muster eigentlich auffallen. Auch geringe
Präsenz der Produktverantwortlichen im Teamalltag begünstigt die
Entwicklung. In dieser Lücke entstehen eigene Gewohnheiten und
stille Freiheiten. Fehlendes Refinement und fehlende Sprintziele
verstärken den Effekt zusätzlich. Ohne Sprintziel wird im Sprint
Planning nie klar, warum ausgerechnet diese eine Story gerade
wichtiger sein sollte als jene andere. Am Ende hilft nur
Konsequenz: solche Beobachtungen dürfen nicht folgenlos bleiben.
Sie brauchen Raum in Retrospektiven, im Refinement und im Sprint
Planning. Dazu gehört auch eine Produktvision, die man immer wieder
neu erzählt, bis sie beim ganzen Team ankommt (oder allen gefühlt
schon zu den Ohren rauskommt). Wer also merkt, dass im eigenen Team
dauernd an Stories gearbeitet wird, die gar nicht wichtig sind,
sollte das als Alarmsignal für den gesamten
Produktentwicklungsprozess verstehen. Oliver und Tim ermutigen
dazu, dieses Storytelling auch mit Werkzeugen künstlicher
Intelligenz auszubauen. So lässt sich die eigene Produktstrategie
in einer Sprache aufbereiten, die im Entwicklungsteam wirklich
verfängt. Folgende frühere Episoden werden im Gespräch genannt: -
Wenn dein Team dir als Product Owner nicht folgt - Mit Storytelling
andere von deinen Produktideen überzeugen - Product Backlog
Refinement - Tipps für Product Owner - Product Principles
(Produktprinzipien) - Verantwortung als Product Owner übernehmen
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.