clockIn Scrum ist der Product Owner als Schnittstelle nach Außen definiert, der Anforderungen der Geschäftsleitung, von Kunden, Fachabteilungen oder Usern einholt und in das Product Backlog überführt. Wie er das macht, bleibt ihm überlassen.

Oft genug steht der geneigte Product Owner vor der schwierigen Situation, mit sehr vage und schwammig formulierten Anforderungen umgehen zu müssen. Wie oft hat man schon Formulierungen gehört wie »Wir brauchen etwas wie …«. Damit können wir allerdings herzlich wenig anfangen. Und genau dort beginnt das Problem. Stakeholder sind keine Produktentwickler. Für sie ist das Ergebnis wichtiger als der Weg dahin. Für das Entwicklungsteam ist jedoch der Weg zum Ziel maßgebend. Die erste Aufgabe des Product Owners ist es also, genau zu verstehen, was der Interessenvertreter eigentlich wirklich will. Kann er seinen Wunsch nicht klar formulieren oder hat er kein konkretes Feature sondern nur ein konkretes Ziel im Auge. An dieser Stelle muss der Product Owner seinen Gesprächpartner mit Fragen löchern, bis auch er ganz genau versteht, worum es eigentlich geht. Was soll das Feature genau bewirken? Was verspricht sich das Unternehmen davon? Gibt es schon eine konkrete Vorstellung davon, wie das Feature aussehen soll was es genau können soll?

Schwer wird es eigentlich nur dann, wenn Anforderungen nur als vage Idee im Raum stehen. In diesem Fall sollte der Product Owner dem Interessenvertreter bei der Ausarbeitung der Idee zu einem konkreten Konzept zur Seite stehen, um ggf. auch schon frühzeitig abzubrechen, wenn sich abzeichnet, dass das Feature in eine Sackgasse läuft, weil z.B. Aufwand in keinem Verhältniss zum Value steht. Der Product Owner sollte bei der Entwicklung der Idee zum Konzept gemeinsam mit dem Interessenvertreter auch die Initiative ergreifen. Er ist derjenige, der die Erfahrung in der Entwicklung solcher Konzepte mitbringt. Achten sie jedoch unbedingt darauf, ihrem Gesprächspartner nicht alles aus der Hand zu nehmen. Letzten Endes ist es seine Idee. Sie kümmern sich um die Details und die Ausführung.

Geht es nun darum, das Feature für Ihr Entwicklungsteam aufzubereiten, ist weitere Detailarbeit gefragt. Ich arbeite gern mit User Stories. Dabei stellen wir uns zu Beginn immer die drei Fragen, wer möchte was warum? Und genau die Antworten stellen den Kern der User Story dar. Das hilft dem Product Owner auch dabei, ein Feature, seinem Entwicklungsteam näher zu bringen. Wenn man den Sinn einer Aufgabe sieht und versteht, fällt sie den meisten Personen wesentlich leichter. Unterschätzen sie diesen Aspekt nicht.
Stellt sich heraus, dass ein Feature sehr komplex ist und sich die Umsetzung sehr wahrscheinlich nicht in wenigen Tagen durchführen lässt, sollte der Product Owner die Anforderung aufsplitten und einen eigenen Themenkomplex – ein Epic – daraus machen, das mehrere priorisierte User Stories enthält.

Die User Stories selbst enthalten nicht nur eine kurze Beschreibung der Anforderung, sondern auch noch eine detaillierte Liste der Abnahmekriterien (Definition of Done). Das kann z.B. sein »Plausibilitätsprüfung bei Eingabe Email-Adresse«. Genauer muss es an dieser Stelle nicht formuliert sein. Ein Entwickler weiß dann schon, was er zu tun hat.
Auch die Formulierung der Story beschränkt sich nicht nur auf einen Satz. Der Product Owner sollte seine Anforderungen so weit ausformulieren, dass sie alle Kernbedingungen des Features enthält. Ggf. kann es auch hilfreich sein, ein Wireframe anzuhängen. Je klarer ein Feature formuliert ist, desto einfacher wird in der Planungssitzung die Schätzung des Aufwands.

twitterrssyoutube
Facebooktwitterredditpinterestlinkedintumblr