Get in touch
Die Welt der Softwareentwicklung hat sich in den letzten Jahren stark gewandelt. Lange Zeit wurden Projekte in der Softwareentwicklung nach einem festgelegten Plan durchgeführt, bei dem jede Phase penibel geplant und dokumentiert wurde (“Wasserfallprinzip”). Doch seit längerem hat sich ein anderer Ansatz etabliert: die agile Softwareentwicklung.
In der agilen Softwareentwicklung sind Teams in der Regel selbstorganisiert und interdisziplinär zusammengesetzt. Die genaue Zusammensetzung kann je nach Projekt und Unternehmen variieren, aber typischerweise umfasst ein agiles Entwicklungsteam Mitglieder aus verschiedenen Fachbereichen wie Entwickler:innen, Designer:innen, Tester:innen und anderen relevanten Rollen. Das Team arbeitet eng zusammen, um die Projektziele zu erreichen und hochwertige Softwarelösungen zu liefern.
Eine wichtige Rolle in agilen Entwicklungsteams nehmen Product Owner:innen ein. Er oder sie ist für das Management des Product Backlogs verantwortlich und hat die Aufgabe, die gewünschten Ergebnisse des Entwicklungsteams zu erreichen. Die Rolle des:der Product Owner:in wurde im Rahmen des Scrum-Frameworks eingeführt, um Herausforderungen bei der Richtungsgebung und Priorisierung von Produktanforderungen zu lösen.
Stefanie Kohlen ist Product Ownerin bei AOE. Schon während ihrer jahrelangen Pressearbeitstätigkeit für Kunden aus dem ITK-Bereich, hat sie ihre Leidenschaft für digitale Projekte entdeckt. So wechselte sie 2007 in das Projektmanagement einer Düsseldorfer Online Agentur und begann ab 2014, sich intensiv mit Scrum und agiler Arbeitsweise auseinanderzusetzen. Seitdem arbeitet sie als zertifizierter Product Owner in diversen – auch skalierten – Projekten und versucht dabei stetig, die Arbeitsweise für Team und Kunden zu verbessern.
Allgemein wird die Rolle der Product Owner:innen oft mit dem englischen Begriff des Value Maximizers beschrieben. Als Product Ownerin bin ich verantwortlich für die Vision des Produktes und dafür, was wann umgesetzt wird. Von zentraler Bedeutung ist dabei das Product Backlog, in dem alle Aufgaben gesammelt und von mir verwaltet werden. Sie sind nach Wichtigkeit, Wert für das Produkt und Grad ihrer aktuellen Ausarbeitung priorisiert. Um diese klare Ausarbeitung zu erreichen, steht der:die Product Owner:in in ständigem Austausch mit dem Kunden bzw. Stakeholdern. Dabei definiere ich die Anforderungen gemeinsam mit ihnen und überführe diese für das Team verständlich ins Backlog. Im Fokus steht hier die Fachlichkeit. Jede:r Product Owner:in sollte ein gutes Verständnis für seine Domäne entwickeln.
Der:Die Product Owner:in ist für die User Stories verantwortlich, die später vom Entwicklungs-Team implementiert werden. Er:Sie muss diese aber nicht zwangsläufig selbst schreiben, sondern kann diese Aufgabe auch delegieren. Das kann aus meiner Erfahrung dann sinnvoll sein, wenn es sich nicht um eine rein fachliche, sondern eher um eine technische Anforderung handelt. Dies können Verbesserungen aber auch der Abbau von technischen Schulden sein. Wichtig ist, dass man sich mit dem Team darüber austauscht und auch diese Dinge im Product Backlog priorisiert. Fragen könnten hier sein: Was passiert, wenn wir dies nicht tun?
… sorge ich dafür, alle notwendigen Informationen zu den von mir priorisierten User Stories zu erhalten. Sind alle Akzeptanzkriterien aus meiner Sicht enthalten? Ist die Story klar beschrieben, sprich sind Ziel, Kundengruppe und Maßnahme klar, sind Abhängigkeiten zu anderen Teams und Systemen transparent und kommuniziert? Oftmals werden solche Punkte auch mit Architekt:in oder Business Analyst:in geklärt. Nichtsdestotrotz habe ich gute Erfahrungen damit gemacht, die Story schon einmal vorab mit jemandem aus dem Team zu beleuchten. Denn unterschiedliche Rollen haben unterschiedliche Sichtweisen und benötigen unterschiedliche Informationen. Priorität hat für mich, dass die User Stories möglichst umfänglich klar sind, um das Ziel des eigentlichen Backlog Refinements zu erreichen.
Bereits vor dem Backlog Refinement teile ich dem Team mit, über welche User Stories ich gern mit ihnen sprechen würde. So können sie sich schon einmal mit den Themen auseinandersetzen und eventuelle Fragen und Anmerkungen vorbereiten.
Im Backlog Refinement stelle ich dem Team die User Stories dann noch einmal grob vor und wir gelangen im besten Fall zu einem gemeinsamen Verständnis und zu einer Schätzung der Story. Wertvoll ist hier vor allem die Sichtweise der verschiedenen Rollen im Team, denn diese tragen zur Vervollständigung der Story bei. Haben wir alle Akzeptanzkriterien erfasst, sowohl funktional als auch nicht-funktional? Erreichen wir damit unser Ziel? Gibt es technische Restriktionen, die unsere Idee erschweren? Gibt es noch offene Fragen, die geklärt werden müssen? Oder ist die Realisierung so schwer abschätzbar, dass wir erst einmal durch einen Spike tiefer in die Materie eintauchen müssen, um mehr Klarheit für die Umsetzung zu bekommen? Für mich ist der gemeinsame Austausch im Team der wichtigste Punkt der Arbeit, denn hier fließen alle Skills zusammen und man erreicht damit das wertvollste Ergebnis.
Bereits vor dem Sprint Planning habe ich mich als Product Ownerin umfassend mit dem laufenden und dem kommenden Sprint beschäftigt. Denn neben der Priorität und der Realisierung der Stories mit dem höchsten Wert sind beim Planen natürlich auch noch ein paar Rahmenbedingungen wichtig. Hier geht es vor allem darum zu klären, wie hoch die Velocity im nächsten Sprint ist. Schaffen wir alle User Stories aus dem laufenden Sprint oder kommt es eventuell zu “Überkippen”? In der Theorie sollte das bestenfalls nicht der Fall sein, aber wir alle wissen, die Praxis ist manchmal anders: User Stories können doch größer werden als ursprünglich gedacht, äußere Umstände können sich als Blocker in einer Story erweisen und manchmal fallen einfach auch Leute aus. Dies alles muss ich berücksichtigen, wenn ich als Product Ownerin den neuen Sprint vor dem Sprint Planning bereits grob plane.
Im Planning selbst gucke ich mir mit dem Team den laufenden Sprint an, um die eventuell kippenden Aufgaben transparent zu machen. Dann schauen wir gemeinsam in die Vorplanung des kommenden Sprints. Sollte sich an den Stories, die ja bereits refined wurden, noch etwas geändert haben, schauen wir noch einmal gemeinsam rein und schätzen bei Bedarf neu. Haben wir das erledigt, frage ich das Team, ob der Sprint für sie so passt. Zeigen alle mit dem Daumen nach oben, ist es gut, ansonsten sprechen wir noch einmal über die Bedenken und justieren entsprechend. Danach formulieren wir gemeinsam ein knackiges und gern auch humorvolles Sprintziel, das allen die Richtung weist, was wir mit dem Sprint erreichen wollen. Der zweite Teil des Plannings gehört dem Entwicklungs-Team. Hier gehen sie zu den einzelnen Stories in den Task Breakdown und erstellen die einzelnen To-dos, die es braucht, um die Story umzusetzen. In den meisten Fällen bleibe ich als Product Ownerin dabei, um eventuell auftretende Fragen klären zu können.
Das Daily Scrum dient vor allem dem Team, sich darüber auszutauschen, was von den geplanten To-dos, die sich jede:r für den Vortag vorgenommen hat, erledigt wurde, und was der Plan für den aktuellen Tag ist. Vor allem aber ist es die Gelegenheit, Blocker, Impediments oder sonstige aktuelle Geschehnisse anzubringen und bestenfalls zu klären oder eine Plan für die Klärung zu finden. Als Product Ownerin bin ich mehr als stille Teilhaberin zugegen und gebe Antworten auf Fragen oder Insights in Neuigkeiten, die das Projekt und/oder das Team betreffen.
Während des laufenden Sprints sind meine Aufgaben als Product Ownerin vielfältig. Einerseits beschäftige ich mich natürlich mit dem aktuellen Sprint. Ich stehe dem Team für alle möglichen Rückfragen und Klärungen zur Seite. Weiterhin habe ich ein Auge auf den Fortschritt im Sprint. Es kann auch einmal vorkommen, dass Dinge schneller fertig werden und die Option besteht, Stories nachzuziehen. Fertige Stories schaue ich mir in der sogenannten PO-Review gemeinsam mit dem:der Tester:in an und nehme sie ab oder hinterlasse Anmerkungen.
Die restliche Zeit verwende ich auf das Backlog, seine Items und deren Priorisierung. Hier geht es darum, die folgenden Stories “reif” zu machen, alle notwendigen Informationen zu sammeln und aktiv mit den Stakeholdern, aber auch mit dem Team zu sprechen.
Die Sprint Review gehört dem Team. Hier stellen sie den Stakeholdern die umgesetzten Stories vor und präsentieren ihre Ergebnisse des Sprints. Für mich ist hier vor allem das Feedback der Stakeholder wichtig. Haben sie Anmerkungen oder Vorschläge? Diese Dinge nehme ich dann wiederum in das Backlog mit auf und priorisiere sie entsprechend.
Die Sprint-Retrospektive dient dazu, einen Blick zurück auf den Sprint zu werfen. Was lief gut, wo hakte es? Über diese Punkte mache ich mir schon vorab Gedanken, um vorbereitet in die Retro einzusteigen.
Wichtig ist hier die Offenheit und das Vertrauen im Team. Man sollte alles ansprechen, das einem aufgefallen ist und das auf der Seele brennt. Denn immerhin ist es unser aller Anspruch, stetig zu lernen, uns zu verbessern und Impediments aller Art aus dem Weg zu räumen. Oft werden auch konkrete Maßnahmen definiert, die sich verschiedene Teammitglieder bis zur nächsten Retro als Task mitnehmen.
