DER EFFEKTIVE „PRODUCT OWNER”:

BASIEREND AUF ERFAHRUNGEN AUS

100 SCRUM-PROJEKTEN BEI SAP

reichen Product Ownern identifiziert wer-den.

In Scrum ist die Rolle des ProductOwners nur rudimentär beschrieben undbietet nur wenig Unterstützung für konkre-te Fragestellungen in der Umsetzung.

FragestellungenFür die weiterführende und erfolgreicheAnwendung von Scrum werden die folgen-den Fragestellungen aus Sicht des ProductOwners betrachtet:

■ Wie sieht eine integrierte Produkt-entwicklung aus, die agile Ideen umsetztund die agilen Vorteile ermöglicht?

■ Welche Rahmenbedingungen sind füreinen effektiven Product Owner in derOrganisation notwendig?

■ Welches Profil ist erforderlich und wiesehen die geeigneten Ausbildungsmaß-nahmen dazu aus?

Agiles ProduktmanagementDer Einsatz von Scrum in Software-projekten bewirkt insbesondere auch einen

Die Einführung von Scrum in einer Organisation bewirkt zusätzlich zu einem neuenund geänderten „agilen” Vorgehen in Softwareprojekten auch Veränderungen desbisherigen Rollenverständnisses. Am markantesten Beispiel, dem Product Owner,wird in diesem Artikel erläutert, wie sich diese neue Rollendefinition bei SAP ent-wickelt hat und welches Profil daraus entstanden ist. Fast unausweichlich entstehtdaraus weiterhin ein an die agilen Vorgehensweisen angepasster Ablauf für dieProduktdefinition, dessen Auswirkungen grundlegend beschrieben werden.

16 17

Christian Schmidkonz

(E-Mail: christian.schmidkonz@sap.com)

ist als Chief Development Architect bei

SAP verantwortlich für innovative

Methoden und Konzepte im Bereich

Softwareentwicklung. Dazu gehört unter

anderem aktuell die erfolgreiche weltweite

Einführung agiler Methoden.

Henrik Stotz

(E-Mail: henrik.stotz@sap.com)

verantwortet als Product Owner das

Produktmanagement von innovativen SAP-

Produkten, wie z. B. das Composite

Application Framework oder den Mobile

Application Modeler. Zukunftsweisende

Ideen setzt er zusammen mit weltweit

operierenden Teams in erfolgreiche

Produkte um.

dass eine im Projekt entwickelte Funk-tionalität, die auch produktiv genutzt wird,früher verfügbar ist. Eine bisher unerreich-te Transparenz wird ebenso bescheinigt wieauch die deutlich höhere Flexibilität in derProduktentwicklung. Eine gesteigerteProduktivität (teilweise wird diese ca. 30 %höher eingeschätzt) sowie erheblich redu-zierte Risiken durch früheres Erkennen vonAbweichungen und technologischenSchwierigkeiten (Risikomanagement) sindweitere positive Erfahrungen.

HerausforderungenSind die Produktvorgaben durch denProduct Owner für das Entwicklungsteamnicht korrekt, nicht abgestimmt oderunklar, kann auch das Produktergebnis desProjekts nicht besser sein. Durch eineUmfrage bei Product Ownern und in derAnalyse kritischer Projekten wurde unteranderem Folgendes festgestellt: Es gabProduct Owner, die z. B. nur bedingt in derLage waren, das Produkt für das Entwick-lungsteam klar und gut genug zu definie-ren. Weiterhin wurde manchen ProductOwnern nicht genügend Zeit für dieseumfassende Aufgabe zugestanden. Auchdie Verfügbarkeit stellte immer wieder einedeutliche Einschränkung dar. In anderenFällen war es den Product Ownern nichtkonsequent erlaubt, die notwendigen Pro-duktentscheidungen bezüglich neuer odergeänderter Anforderungen zu treffen. Diesist auf eine fehlende Akzeptanz der Rolle inder Organisation zurückzuführen.

Dagegen war ein guter Product Ownerimmer ein entscheidender Erfolgsfaktor beiden überdurchschnittlich gut abschneiden-den Projekten. Persönliche Eigenschaftenkombiniert mit fachlichen Kompetenzen,die auch eine gewisse Reife und Erfahrunggewährleisteten, konnten bei allen erfolg-

Ausgangslage

Scrum und der Product OwnerDie seit Ende 2005 begonnene und welt-weit sehr erfolgreiche Einführung vonScrum bei SAP konnte in 2007 fortgeführtwerden (siehe Abb. 1). Scrum hat sich infast allen (über 90 %) Scrum-Projekten beiSAP als effiziente und akzeptierte Methodefür die Entwicklung von Softwareproduk-ten etabliert.

Der Product Owner spielt in Scrum einezentrale und entscheidende Rolle. Er istverantwortlich für den Erfolg des Produktsam Markt und hierbei in einer Füh-rungsrolle. Seine Aufgabe beginnt mit derEntwicklung der Produktvision und derdavon abhängigen Ableitung von Szena-rien, Prozessen und Funktionalitäten. Imnächsten Schritt bildet er die Anfor-derungen ab, die im Projekt zum Produktumgesetzt werden sollen. Hierzu stellt eriterativ die Vorgaben für das Projektteamzur Verfügung und erläutert und vermitteltdiese. Er verantwortet die Inhalte undPrioritäten der Produktanforderungen.Letztendlich nimmt er auch das vom Teamentwickelte Produktergebnis nach jederIteration sowie am Projektende ab. Dabeiist die regelmäßige Überprüfung undAbstimmung der Planung und der vorlie-genden Ergebnisse mit dem Markt/Kundenund der firmeninternen Strategie notwen-dig.

Die stetig steigende Akzeptanz vonScrum hat hier deutliche Vorteile gegenü-ber bisherigen Verfahren im Projekt-management gezeigt. So gut wie alle Pro-jekte berichten, dass sie mehrere derversprochenen agilen Nutzen durch dieAnwendung von Scrum erfahren konnten(siehe auch Abb. 2): eine erhöhte Produkt-qualität, insbesondere auch in dem Sinne,

d ie au torenschwerpunk t

3 / 2 0 0 8

neuen Umgang mit der Produktdefinitionund in der Entwicklung des Produkts imProjekt. Die zentrale Rolle ist hier derProduct Owner.

Positionierung und Auftragdes Product OwnersDer Product Owner ist verantwortlich fürden Erfolg des Produkts am Markt. Dafürist es neben dem notwendigen Wissen undden Fähigkeiten unabdingbar, dass er inseiner Rolle vom Management positioniertwird und mit den erforderlichen Entschei-dungsbefugnissen versehen ist. In derZusammenarbeit mit den Stakeholdernmuss klar geregelt sein, dass der ProductOwner letztendlich die Entscheidungenbezüglich Prioritäten und Inhalten trifft.Selbstverständlich gilt das in der Zu-sammenarbeit und Abstimmung mit denStakeholdern. Dieser Auftrag wird an denProduct Owner offiziell vergeben. Diezugesicherte Verfügbarkeit des ProductOwners für das Projekt beträgt dabei min-destens 70 % seiner Kapazität.

Produktvision und Business-CaseBasierend auf den bekannten Markt- undKundenanforderungen sowie den produkt-strategischen Unternehmenszielen bildetder Product Owner die Vision und führteine Managemententscheidung bezüglichder geplanten Investition her. Das Ergebnisist ein geplanter Produktfokus und eineInvestitionshöhe für das kommende Re-lease. Berücksichtigung finden hierbei ins-besondere auch die Ziele, die mit demProdukt am Markt erreicht werden sollen,und der damit erwartete Umsatz. DerProduct Owner sollte in der Lage sein,Vision und Ziele in zwei bis drei Minutenkurz und verständlich darzustellen.

ProduktdefinitionAusgehend von der abgestimmten Produkt-vision beginnt der Product Owner mit derDefinition der abzubildenden (z. B.betriebswirtschaftlichen) Abläufe und derProduktgrobplanung in Zusammenarbeitmit den zuständigen Entwicklungsberei-chen. Danach wird die sich daraus erge-bende Funktionalität identifiziert, in einerPlanung erfasst und mit Prioritäten ausMarktanforderungssicht versehen. Dabeiwird zwischen Kern- und Nebenfunktio-nalität unterschieden.

Im nächsten Schritt findet die grobeSpezifikation jeder Funktionalität statt, eswerden die technischen sowie betriebswirt-schaftlichen Prozessabhängigkeiten ermitteltund die grundlegenden architektonischenAnforderungen definiert. Insbesondere sindauch die Abhängigkeiten zu zulieferndenEntwicklungsbereichen dargestellt. Ab-schließend werden in einer integriertenPlanung Termine und Inhalte vereinbart.Weiterhin sind die Anforderungen an dasProdukt auch für die relevanten Produkt-standards (wie z. B. Security, Accessibility,Performance) festzulegen. Anforderungenkönnen in jedem Fall auch von Stakeholdernüber den Product Owner eingebracht wer-den. Scrum ermöglicht auch eine inkremen-telle Produktdefinition.

Nach der ersten Planungsrunde findetgemeinsam mit der Entwicklung eineGrobschätzung des Aufwands des geplan-ten Produkts statt. Die sich daraus erge-benden möglichen Zieltermine werden fest-gelegt. In Abstimmung mit denStakeholdern wird nun der vorgeseheneFunktionsumfang vereinbart und dergeschätzte Grobaufwand wird mit demgeplanten Budget abgeglichen. Bei Bedarferfolgt eine Anpassung von Funktionalitätbzw. Budget. Das Ergebnis ist ein definier-ter Funktionsumfang mit Prioritäten miteinem geplanten Grobaufwand und einemZieltermin.

schwerpunk tschwerpunk t

Abb. 1: Entwicklung der Verwendungvon Scrum bei SAP.

Abb. 2: Erwartete Nutzen bei Anwen-dung von Scrum und agilen Methoden inProjekten.

Für diesen verabschiedeten Funktions-umfang erfolgen nun bei Bedarf eine weite-re Verfeinerung und Konkretisierung derAnforderungen. Im nächsten Schritt wirdzusammen mit dem zuständigen Qualitäts-verantwortlichen eine Teststrategie defi-niert sowie ein grober Testplan erstellt.Gleichzeitig wird entsprechend demgeplanten Aufwand das Entwicklungsteammit den erforderlichen Fähigkeiten für denvorgesehenen Zeitraum aufgestellt.

Ist der grobe Funktionsumfang verabschie-det, kann die Grobspezifikation derFunktionen auch in Iterationen erfolgen. D.h.nach Priorität wird in einem erstenProduktdefinitions-Sprint für die freigegebeneKernfunktionalität die Grobspezifikationerstellt. Während der der anschließendenEntwicklung kann parallel die Grob-spezifikation für die weitere Kernfunktio-nalität stattfinden.

Letztendlich erfordert die Umsetzungeines Produkts mit Scrum einen angepass-ten Umgang mit der Produktdefinition. DerProduct Owner leitet die Produktdefi-nition, im Idealfall bereits teilweise inZusammenarbeit mit dem Scrum-Master.

Agile Produktentwicklung mit ScrumDer Ablauf der Softwareproduktentwicklungmit Scrum bei SAP besteht aus der Sprint-Vorbereitung, dem Sprint-Planungstermin,der Durchführung des Sprints und demSprint-Review (siehe auch Abb. 3).

In der Sprint-Vorbereitung wählt derProduct Owner nach Priorität die aktuellwichtigste Kernfunktionalität aus und spe-zifiziert im nächsten Schritt die Groban-forderungen, die im folgenden Sprint ent-wickelt werden sollen. Daraus abgeleiteterfolgt die verfeinerte Definition dergeplanten Anforderungen, jeweils mitPrioritäten versehen. Der Product Ownerachtet auch insbesondere darauf, dass fürden folgenden Sprint alle notwendigenAnforderungen definiert und verfügbarsind, die es ermöglichen, ein vollständigesund funktionierendes Produktinkrement indiesem Sprint zu entwickeln. D. h. es sindbeispielsweise zusätzlich zu den funktiona-len Aspekten auch die Anforderungen zuTest, Dokumentation, Produktstandardsund Integration für dieses Produktinkre-ment entsprechend dem SAP-Standard defi-niert.

Für jede Anforderung legt der ProductOwner zusätzlich die Abnahmekriterienfest: das, was am Ende eines Sprints zumReview verfügbar sein soll und was damit

Owner einvernehmlich und verbindlich daszu liefernde Produktinkrement (Sprint-Ziel) und den Liefertermin (Sprint-Review).

Während des Sprints hält sich derProduct Owner in jedem Fall an die Regel,dass vereinbarte Anforderungen (Sprint-Ziel) während des Sprints nicht mehr geän-dert werden dürfen. Er nimmt in Abstim-mung mit dem Team am Daily Scrum teil(in dem er nicht sprechen darf), um imAnschluss mögliche aufgetretene Fragen zuklären. Er bekommt hier auch einenEindruck vom Entwicklungsfortschritt.Grundsätzlich ist er während des Sprintsfür das Team für produktrelevante Fragenin einer vereinbarten Form verfügbar. Hierhat sich auch eine regelmäßige Sprech-stunde des Product Owners für Fragen undauch erste Produktvorführungen währenddes Sprints bewährt. Hauptaufgabe desProduct Owners ist es, parallel zum Sprintdie Vorbereitungen für den nächsten Sprintdurchzuführen und dabei auf neue undgegebenenfalls geänderte Anforderungenzu achten. Sollte das Team mit dem geplan-ten Entwicklungsumfang früher fertig sein,entscheidet er auf Anfrage über weitereAnforderungen, die aufgenommen werden.Im Sprint-Review wird betrachtet, wasgeplant war, was im Sprint entwickelt wur-de und welches Produktinkrement funktio-nierend verfügbar ist. Die Funktionalitätwird vom Team in einer Demo vorgeführtund zusammen mit Product Owner undStakeholdern diskutiert. Für die Team-motivation ist darauf zu achten, dass derProduct Owner die Erfolge mit Lob hono-riert. Erledigte Anforderungen nimmt erformal ab und bestätigt dies mit dem Status„abgenommen”, falls die in der Planungdefinierten Abnahmekriterien erfüllt sind.Für verbesserungswürdige Punkte übt erkonstruktive Kritik (Team-Feedback).Zusammen mit den Stakeholdern wirddiskutiert, was daraus im nächsten Sprintgegebenenfalls fertig gestellt werden soll,welche Anforderungen angepasst werdenund welchen möglichen Einfluss das Sprint-Ergebnis auf den nächsten Sprint hat.Dabei werden eventuell aufgetreteneSchwierigkeiten (z. B. im Bereich Techno-logie oder Tools) mit berücksichtigt. AmEnde des Reviews wird der nächste Sprint-Planungstermin bestätigt bzw. vereinbart.

Der Product Owner bereitet nun denBacklog für den nächsten Sprint auf Basis dervorbereiteten Planung und unter Berück-sichtigung der Ergebnisse aus dem Reviewvor. Bei Bedarf erfolgt eine weitere Ab-

18 19

ausgewählten Anforderungen werden alsSprint-Backlog bezeichnet. Weiterhin for-muliert der Product Owner auch dasgewünschte Abnahmeziel für den Sprintkurz und verständlich in ein bis zweiSätzen. Alle Fragen aus dem Entwick-lungsteam werden mit ihm diskutiert undgeklärt. Ziel ist es, alle Anforderungen ausSicht des Teams soweit vollständig und klarverständlich definiert und vermittelt zubekommen, dass das Team die Aufga-benplanung durchführen kann. Anfor-derungen, die im Planungsmeeting nichtausreichend gut erläutert und geklärt wer-den können, dürfen schlimmstenfalls vomTeam für den anstehenden Sprint abgelehntwerden. Das soll verhindern, dass auf Basisunklarer Vorgaben eine Entwicklunggestartet wird, die sehr wahrscheinlich einfalsches Ergebnis liefert. Dabei wird mitdem Product Owner besprochen, welcheproduktspezifischen Fragestellungen ausSicht des Teams für diese unklarenAnforderungen zu klären sind. ImPlanungsmeeting können außerdem Anfor-derungen und Prioritäten bei Bedarf ange-passt und ergänzt werden – das ist in jedemFall zu dokumentieren. Das Team entschei-det jetzt, ob der Sprint mit einem ausführ-licheren Design beginnt („Design-Tag”).

Hat das Team nach eigener Aussage diegewünschten Anforderungen verstanden,wird für jede Anforderung der Aufwandvon diesem geschätzt. Ist die Summe derAufwände nun deutlich größer oder kleinerals die verfügbare Teamkapazität, entschei-det der Product Owner, was gegebenenfallsheraus- oder hinzugenommen wird. DieseAnpassung erfolgt gleichfalls nach Be-trachtung der Summe der Aufwände ausder Aufgabenplanung des Teams. Ab-schließend vereinbaren Team und Product

Voraussetzung für die Abnahme desProduktinkrements ist. Alle verfügbarenAnforderungen werden im so genanntenProdukt-Backlog erfasst. Es ist empfehlens-wert, mehr Anforderungen verfügbar zuhaben, als im geplanten Sprint vom Teamvoraussichtlich erledigt werden können.Damit ist eine größere Flexibilität in derPlanung gewährleistet. Dieser Ablauferfolgt in Zusammenarbeit mit demArchitekten bezüglich Architekturfragen.Gemeinsam mit ausgewählten Leuten ausdem Entwicklungsteam wird vorab eineerste Schätzung der Anforderungen im ver-fügbaren Produkt-Backlog durchgeführt.Ziel ist es, dass jede Anforderung möglichstim folgenden Sprint erledigt werden kann.Der Product Owner trifft jetzt eine ersteEntscheidung über das gewünschte Sprint-Ziel. Die Anforderungen, Ziele, Inhalteund Prioritäten für den anstehenden Sprintstimmt er abschließend mit den Stake-holdern ab.

Im ersten Sprint-Planungstermin desProjekts werden vom Product Owner ein-leitend die Produktvision und -ziele,Markt- und Kundenanforderungen sowieder (z. B. betriebswirtschaftliche) Ablaufbzw. Prozess vorgestellt. Sind weiterhinrelevante technologische Vorgaben vorhan-den, werden diese ergänzend dargestellt.Danach erläutert der Product Owner dengeplanten Funktionsumfang für das Pro-dukt (Feature-Plan). In den folgendenPlanungsterminen wird zu diesen Punktenberichtet, falls Änderungen vorliegen.

In jedem Planungstermin stellt derProduct Owner den gewünschtenFunktionsumfang für den anstehendenSprint und die dazugehörigen Anforderun-gen im Detail vor – inklusive des jeweiligenAbnahmekriteriums. Die für den Sprint

schwerpunk t

Abb. 3: Scrum-Ablauf in einem SAP-Softwareprojekt.

3 / 2 0 0 8

stimmung mit den Stakeholdern bezüglichInhalten, Änderungen und Prioritäten. Hierist zu beachten, dass ausreichend Zeit vor dernächsten Sprint-Planung zur Verfügung steht.

Außerdem stellt der Product Owner nachjedem Review einen aktualisierten Produkt-bzw. Projektstatus (Projekt- bzw. Release-Burndown) auf Basis des geplanten Funk-tionsumfangs zur Verfügung (z.B. „X % desgeplanten Kernfunktionsumfangs sind ver-fügbar”). Er berichtet damit nach jedemSprint den Fortschritt der Produktentwick-lung und die dafür benötigten Aufwände.

Für die Risikobetrachtung sind unteranderem die aktuell vorliegenden Produkt-ergebnisse, die Technologie und diePrognose über das zu erwartende Projekt-ergebnis zum geplanten Termin mit einzu-beziehen (z. B. unter Anwendung von„Agiler Planung und Schätzung”). Dasgeschieht in Zusammenarbeit mit Teamund Scrum-Master.

Gegebenenfalls entscheidet der ProductOwner auch über eine Reduzierung desursprünglich geplanten Funktionsumfangs.Das ist dann sinnvoll, falls sich herausstellt,dass zum Zieltermin nicht alles geliefertwerden kann und andere Lösungen (z. B.Erhöhung der Teamkapazität) nicht mög-lich sind. In solchen Fällen ist es das Ziel,dass die wichtigste Kernfunktionalitätmarktgerecht und mit hoher Qualität zurVerfügung gestellt werden kann. ImIdealfall werden Kunden zu Sprint-Reviewseingeladen, um die verfügbare Kernfunk-tionalität zu verifizieren.

Im Sinne von „Time-to-Market” kannein Product Owner über die Voraus-

lieferung eines Teils des Produkts entschei-den. Das bedeutet, dass eine für den Marktsehr wichtige Kernfunktionalität verfügbarist. Dafür werden dann im nächsten Sprintalle Aktivitäten durchgeführt, die dieAuslieferung ermöglichen. Dabei ist auf dieVollständigkeit des Produkts im Sinne allerStandards zu achten. Auch die Voraus-lieferung unterliegt einer vorangegangenenAbnahme und Validierung.

Der Ablauf der Produktentwicklungnach Scrum erfolgt unter Leitung desScrum-Masters in enger Zusammenarbeitmit dem Product Owner.

Für größere Produkte bzw. Projekte wer-den in Scrum mehrere Teams gebildet. Fürein Projekt mit zwei oder drei Teams kannes noch mit einer Person als Product Ownerfunktionieren. Ab drei Teams wird emp-fohlen, über die Notwendigkeit von Teil-produkt Ownern zu entscheiden. Dabeigibt es einen „Hauptprodukt Owner”, derdie Entwicklung aus Gesamtproduktsichtkoordiniert. Die Teilprodukt Owner sindfür den Bereich ihres jeweiligen Projektsverantwortlich. In solchen Fällen ist für dieProduktentwicklung in der Regel eine nochumfassendere Planung notwendig. Diesbeinhaltet insbesondere auch die Planungund Definition der funktionalen Abhängig-keiten zwischen den zu entwickelndenProduktbereichen der Teams.

Für Dokumentation, Test und Überset-zung wird nun auf Programmebene geplantund koordiniert. In der Sprint-Vorbereitungwird entschieden, welche Funktionalität imnächsten Sprint entwickelt werden soll.Teilnehmer sind hier alle Product Owner,

Scrum-Master und Stakeholder für dasProdukt. Als Ergebnis der Vorbereitung stehtfür jedes Team ein Produkt-Backlog zurVerfügung, der vom zuständigen TeilproduktOwner erstellt wurde. Der HauptproduktOwner verantwortet hier das Gesamtbudgetim Sinne der Entwicklungskapazitäten. Erentscheidet, nach welchen Prioritäten dasProdukt entwickelt wird. Hierfür ist er auchgegenüber Stakeholdern und Managementverantwortlich.

Die Rolle des „ProductOwners” in der Organisation

Product-Owner-InterviewsUm die Ausbildungsbedürfnisse und not-wendigen Fähigkeiten für Product Ownerzu ermitteln, wurde mit zehn ProductOwnern ein ausführliches Interviewgeführt. Die Zielgruppe hatte unterschiedli-che Erfahrungshintergründe und wurde ausvier internationalen Standorten ausge-wählt. Sie betreute Entwicklungsprogram-me zwischen 10 und 100 Personen. Dasstrukturierte Interview bezog sich auf dieKommunikation, die Kontrolle undProzesse für die drei Bereiche Product-Owner-Rolle, Produktdefinition undProduktentwicklung.

Profil des Product OwnersAus den Ergebnissen der Interviews undden Erfordernissen der Entwicklung undder Organisation hat sich das im Folgendenbeschriebene Profil ergeben. Um eineProduktentwicklung erfolgreich mit Scrumumsetzen zu können, benötigt ein ProductOwner persönliche, strategische und ope-rationale Fähigkeiten (siehe Abb. 4).

Der Product Owner hat die Verant-wortung für den Erfolg des Produkts unddamit die Führung für die Produkt-definition. Da es sich in diesem Kontext umeine informelle Leitung handelt, sind per-sönliche Fähigkeiten unverzichtbar. Dazuzählen die Ausstrahlung einer natürlichenAutorität sowie ein vertrauenswürdigesund glaubwürdiges Verhalten. Diese Fähig-keiten sind erforderlich im Umgang mitStakeholdern, Kunden und Managementfür die Definition und Verhandlung desProdukts. Für die Zusammenarbeit mitdem Team zählen zusätzlich Motiva-tionsfähigkeiten. In seinem Umfeld verkör-pert der Product Owner die agilen Werte:

■ der Mensch im Mittelpunkt■ funktionierende Software

schwerpunk t

Abb. 4: Product-Owner-Kompetenzen.

mit den notwendigen Vollmachten ausge-stattet werden. Ein offizieller Auftrag vomSenior Management an den Product Ownerstellt eine weitere wichtige Positionierungdar.

Im Weiteren ist eine offizielle HR-Rolle(Human Resources) mit der zugehörigenStellenbeschreibung für die Akzeptanz derPosition besonders wichtig. Dazu gehörtauch die Einführung von Karriereebenen,die die Erfahrung und die Verantwortungwiderspiegelt (z. B. Junior, Senior). Zu jederEbene ist neben einem Profil auch die pas-sende Ausbildung zu definieren und anzu-bieten. Für die Weiterentwicklung werdendie Kriterien festgelegt, die die Voraus-setzungen für die nächste Entwicklungs-stufe darstellen.

Typische Kandidaten für den Einstieg indiesen Karrierepfad haben über fünf JahreBerufserfahrung und besitzen ein starkesNetzwerk. Eine Unterscheidung – beispiels-weise zwischen Junior und Senior ProductOwners – bietet die Chance, interessierteMitarbeiter früh auf diese Laufbahn vorzu-bereiten.

Das vorgestellte Modell (siehe Abb. 5)bietet eine wichtige Grundlage, um die Rolleinnerhalb einer Organisation zu etablieren.Damit ist eine wesentliche Voraussetzungerfüllt, damit die Rolle effektiv und aucheffizient wahrgenommen werden kann.

Ausbildung und TrainingDie bisherigen Erfahrungen aus Scrum-Projekten haben gezeigt, dass die bishervorhandenen Ausbildungsmaßnahmennicht ausreichend sind, um Personen auf

20 21

Usability) für die Produktdefinition notwen-dig, um den Produkterfolg am Markt zugewährleisten. Abschließend verantwortet erdie Durchführung der Validierung und teil-weise die Auslieferung des Produkts. Dazugehört die frühzeitige Abstimmung undPlanung der Termine und Aktivitäten mitden zuständigen Bereichen.

Für größere Produkte fungiert derProduct Owner als Programmmanager.Dabei umfasst die Entwicklung zwei odermehr Teams. Hier ist in der Regel eineumfangreichere und komplexere Produkt-planung gegeben. Es gilt zunächst, dieFunktionalität für den neuen Sprint festzu-legen. Anschließend erfolgt eine Abhängig-keitsplanung innerhalb der Funktionalität.Dabei wird auch ermittelt, wie die Teams inihrem Sprint mit den Entwicklungen von-einander abhängen. Häufig ist es sogarsinnvoll, zwei Sprints im Voraus zu planen.Hier wird z. B. festgestellt, welche Ent-wicklungen im nächsten Sprint alsVoraussetzung notwendig sind, damit imübernächsten Sprint die geplante Funk-tionalität entwickelt werden kann. Dazugehört auch die übergeordnete Ko-ordination von Test, Dokumentation undÜbersetzung (der Softwaredokumentationund der verwendeten Texte, z. B.Meldungstexte, Bildschirmtexte) auf Ge-samtproduktebene.

Der Product Owner verantwortet gegen-über Stakeholdern und Management auchdas Budget im Sinne der Entwick-lungskapazität. Diese Kapazität wird regel-mäßig überprüft. Hierzu wird auf Basiseiner Schätzung eine Aussage für daserwartete Ergebnis zum Zieltermin aufBasis des bisherigen Entwicklungsstandesgemacht. Dabei kann es durchaus zuMeinungsunterschieden bei den beteiligtenGruppen kommen und häufig ist politi-sches Geschick so wertvoll wie hartesFaktenwissen.

Product Owner in der OrganisationBislang wurde die Rolle des ProductOwners informell wahrgenommen. Perso-nen, die die wichtigen Voraussetzungenmitbrachten (persönlich, strategisch undoperational), haben die Funktion übernom-men. Dabei ist die verfügbare Zahl der inFrage kommenden Personen begrenzt. Mitder stark gewachsenen Verbreitung vonScrum ist eine formale Einordnung in dieOrganisation immer wichtiger geworden.Zunächst sollte in der Organisations-struktur die Rolle vorgesehen werden und

■ Zusammenarbeit mit dem Kunden■ Reagieren auf Änderungen.

Das wird oft nicht automatisch angenom-men. Dazu leistet der Product Owner in sei-nem Bereich Überzeugungsarbeit für agileMethoden bzw. Scrum. Hier sind seineVeränderungskompetenzen besonders ge-fragt.

Wirksame Veränderungen bedürfenunter anderem einer ausgezeichneten Kom-munikation mit den betroffenen Gruppenund Personen. Die Fähigkeit, Verhand-lungen über das Produkt, dessen Anfor-derungen und das erforderliche Budget zuführen, ist unerlässlich. Da wir uns regel-mäßig in einem Markt mit vielen Kundenbefinden und unsere Organisation sehrvielschichtig und weitreichend ist, ist dasPflegen eines persönlichen Netzwerks einweiterer entscheidender Erfolgsfaktor. DasNetzwerk zielt auf die Bereiche Kundenund Management in der Feldorganisationund in Technologiethemen. Das alles findetin einem internationalen Kontext statt, indem interkulturelle Fertigkeiten unver-zichtbar sind.

Der Product Owner leitet die Produkt-definition. Dazu benötigt er Experten-fachwissen über die Prozesse, Abläufe undMarktanforderungen in diesem Bereich.Die neue Produktidee diskutiert er mit die-sen Kunden, der Feldorganisation und deninternen Stakeholdern. Anschließend ent-wickelt er daraus eine Produktvision undführt diese in Diskussionen zu einergemeinsam getragenen Vision der Betei-ligten. Für den erfolgreichen Umgang mitKunden und internem Management sindKenntnisse der organisatorischen Struk-turen wichtig. Diplomatisches Geschick istgefragt bei der Verhandlung und auch beimDurchsetzen wichtiger Produktmerkmalein der Produktdefinition.

Der Product Owner benötigt insbesonderedie Fähigkeit, die Produktvision schrittweisein Prozesse, Funktionen und schließlichAnforderungen systematisch umzusetzen.Dazu ist die genaue Kenntnis des firmenin-ternen Prozesses und der Vorgehensweisenunabdingbar. Ausgehend von einem von ihmerarbeiteten Funktionalitätsplan (z.B. für einRelease) werden gültige Anforderungen (z.B.„testbar”, „klar” und „einfach verständ-lich”) für den Produkt-Backlog abgeleitetund festgelegt. Ergänzend ist ein umfangrei-ches Wissen über die erforderlichen Produkt-standards (nicht-funktionale Anforderungen,wie z.B. Security, Performance, Accessibility,

schwerpunk t

Abb. 5: Definition der Product-Owner-Rolle in der Organisation.

3 / 2 0 0 8

die Product-Owner-Rolle vorzubereitenund darin zu unterstützen. Hierfür wurdeein neues Ausbildungskonzept entwickelt.

VoraussetzungenAls Ergebnis der Umfrage wurde festge-stellt, dass die meisten Product Owner

bereits einige entscheidende Grundvoraus-setzungen mitbringen. In einigen wichtigenBereichen des beschriebenen Profils haben

schwerpunk t

Agile Planung & Schätzung Verfahren zur Aufwandschätzung. Dabei werden die Anforderungen zunächst in Punkten nach Aufwandund Schwierigkeit vom Team bewertet. Erst am Schluss werden die Punkte in eine Zeiteinheit umgesetzt.Vorteil ist hier, dass die Aufwandsermittlung zeitlich vom Bewertungsvorgang entkoppelt ist. DasVerfahren ist zunächst zeitunabhängig und damit genauer.

Feature-Plan siehe FunktionalitätsplanFunktionalitätsplan Basierend auf den definierten abzubildenden (z. B. betriebswirtschaftlichen) Abläufen ermittelt der

Product Owner die erforderliche Funktionalität. Diese wird in einer Planung erfasst und mit Prioritätenaus Marktanforderungssicht versehen. Ausgehend von dem Funktionalitätsplan wird nach jedem Sprintder Projektfortschritt berichtet.

Produkt-Backlog Der Produkt-Backlog enthält alle Anforderungen an das Produkt und Aufträge (z. B. Dokumentation undTest) an das Team, um ein vollständiges und funktionierendes Produktinkrement zu entwickeln.

Produktdefinintions-Sprint Besonders für Scrum-Projekte ist es sinnvoll, auch die Definition des Produkts inkrementell in Sprintsdurchzuführen. Dabei wird die wichtigste Funktionalität aus Marktsicht zuerst in Anforderungen defi-niert und an das Team für die Entwicklung weitergegeben. Parallel zur Entwicklung im Sprint wird dernächste Funktionalitätsumfang in Anforderungen umgesetzt.

Produktinkrement Als Produktinkrement wird die lauffähige, getestete und dokumentierte Software bezeichnet, die aufBasis der Anforderungen aus dem Produkt-Backlog entwickelt wurde. Das Produktinkrement (auch„Potentially Shippable Product Increment” genannt) ist das Ergebnis eines Sprints.

Product Owner Person, die für den Erfolg eines Produkts am Markt verantwortlich ist. Er bildet anfangs eine Vision unddefiniert daraus abgeleitet alle Anforderungen im Produkt-Backlog, die inkrementell im Projekt umge-setzt werden. Er ist verantwortlich für Korrektheit, Vollständigkeit und Prioritäten der Anforderungen.

Release-Burndown Der Release-Burndown beschreibt den Produktfortschritt in der Entwicklung im Projekt. Ausgehendvom Funktionalitätsplan wird festgestellt, zu welchem Grad das Produkt fertiggestellt ist und was vonder geplanten Funktionalität noch offen ist. Vor allem kann auf Basis der bisher erbrachten Aufwände,der geplanten Projektkapazität und der erstellten Funktionalität eine Prognose abgeleitet werden, waszum geplanten Projektende voraussichtlich verfügbar sein wird. Der Release-Burndown wird nach jedemSprint-Review fortgeschrieben.

Scrum-Master Person, die für den Ablauf des Projekts nach Scrum verantwortlich ist. Er organisiert alle Scrum-Meetings und stellt den Ablauf nach Scrum sicher. Der Scrum-Master hilft dem Team, Schwierigkeitenim Projekt zu lösen, und fungiert als Team-Coach.

Sprint Ein Sprint ist ein Software-Entwicklungszyklus im Projekt, in dem Anforderungen aus dem Produkt-Backlog in ein Produktinkrement umsetzt werden. Er dauert in der Regel zwischen zwei und fünfWochen. Jeder Sprint beginnt mit einer Sprint-Planung und endet mit einem Sprint-Review. Ein Scrum-Projekt besteht aus einer Anzahl von Sprints.

Sprint-Backlog Sprint-Ziel, ergänzt im Sprint-Planungsmeeting mit den geplanten Entwicklungsaufgaben durch dasTeam.

Sprint-Planung Im Sprint-Planungsmeeting werden alle vom Product Owner gewünschten Anforderungen für den Sprintmit dem Team besprochen. Das Team schätzt die Anforderungen und erstellt danach eineAufgabenplanung für den Sprint. Ist der geschätzte Aufwand für das geplante Sprint-Ziel zu hoch oderniedrig im Vergleich zur verfügbaren Kapazität, wird in der Regel der Umfang des Sprint-Ziels entspre-chend angepasst. Am Ende wird das Sprint-Ziel verbindlich vereinbart.

Sprint-Ziel Das Sprint-Ziel sind die ausgewählten Anforderungen aus dem Produkt-Backlog, die vom Team an denProduct Owner im Sprint-Planungsmeeting als zugesichertes Ergebnis für den anstehenden Sprint ver-bindlich vereinbart werden.

Stakeholder Personen, die weitere Anforderungen an das Produkt (Projekt) haben und diese über den Product Ownereinbringen. Typischerweise sind das Vertreter z. B. vom Management und anderen Produktbereichen.

Sprint-Review Meeting am Ende eines Sprints, in dem Team, Product Owner und Stakeholder gemeinsam das vorlie-gende Entwicklungsergebnis eines Sprints betrachten und diskutieren. Das Produktinkrement wird dabeiin einer Demo vorgeführt.

Team Entwicklungsteam, das die Anforderungen aus dem Produkt-Backlog in ein Produkt umsetzt. Das Teamarbeitet im Sprint eigenständig und organisiert sich selbst. Es gibt keine Hierarchien im Team.

Kasten 1: Glossar der verwendeten Begriffe in der agilen Softwareentwicklung.

■ Product Owner in einem Scrum-Projekt(unternehmensspezifische Ausbildung)

Für die erforderliche persönliche Entwicklungund die effektive und erfolgreicheAnwendung der Fertigkeiten wird einMentoring angeboten. Die individuellen Zieledes Mentorings werden zu Beginn gemeinsamnach den persönlichen Bedürfnissen verein-bart. Dabei unterstützt ein erfahrener ProductOwner in regelmäßigen Terminen den neuenProduct Owner. Der Mentor stößt die per-sönliche Entwicklung an und überprüftgemeinsam mit dem Klienten die Fortschritte.Die Dauer beträgt üblicherweise ca. dreiMonate bei ca. zehn bis zwölf Terminen zujeweils 30 bis 60 Minuten. ■

22 23

■ Zuhören und Kommunikation■ Argumentationstechniken■ Konfliktmanagement■ Führen durch Motivation■ Aufbau von Vertrauen■ Management von Veränderungspro-

zessen■ Interkulturelles Training (kulturspezi-

fisch)■ Projektmanagement■ Anforderungsanalyse und -management■ Produktstandards und Entwicklungs-

prozess (unternehmensspezifisch)■ Tools für das Projekt- und Anfor-

derungsmanagement (unternehmens-spezifisch)

■ Scrum-Grundlagen

jedoch alle in Teilbereichen einen deut-lichen Bedarf an Weiterbildung undUnterstützung.

Die grundlegendsten Voraussetzungensind das Expertenfachwissen im Produkt-bereich, das Wissen und die Fähigkeit dasProdukt zu definieren. Ergänzend dazugehört die persönliche Fähigkeit, mit denzuständigen Unternehmensbereichen effek-tiv zu kommunizieren und zu arbeiten. DieBereitschaft, nach agilen Werten zu arbeitenund die Verantwortung für ein Produkt zuübernehmen, ergibt gute Voraussetzungenfür einen erfolgreichen Product Owner.

Folgende Themen sind für die Aus-bildung von Product Ownern vorgesehen:

schwerpunk t