Menschen, die dieses breite und tiefe Anforderungsprofil erfüllen, finden sich in der industriellen Praxis selten in einer Person. Aus diesem Grund haben wir aus dem einzelnen Product Owner das Product-Owner-Team (POT) entwickelt. Das POT bestehend aus: Produktmanager (Markt), Systemingenieur (Technik) und Projektmanager (Projekt).

Durch die Idee des Product-Owner-Teams konnten wir in den Unternehmen eine deutliche Entspannung erreichen: Keine der drei Rollen hat eine Unter- oder Überstellung zu befürchten, die Suche nach der einen »Extremqualifikation« fällt weg. Außerdem muss keine neue Funktion geschaffen werden.

1. Der Projektleiter ist nicht allein. Die Projektführung ist ein Führungs-Team. Die drei relevanten Perspektiven: Markt, Technik und Projektmanagement sind mit Profis aus jedem einzelnen Fachgebiet besetzt. Keiner legt das Ziel einseitig oder unabhängig von den anderen fest. Drei Sparringspartner arbeiten alle zwei Wochen gemeinsam an dem besten Sprint-Ziel für ein Team. Die Qualität der Ziel-Definition steigt.

2. Der MARKT ist integriert. In den meisten Unternehmen reduziert sich die aktive Rolle des Marktes, also des Produktmanagements im Wesentlichen auf die Lastenhefterstellung und die Markteinführung. Bei AGILE ist der Markt alle zwei Wochen mit den kapazitiven Möglichkeiten der Technik konfrontiert. So hat die lange Liste der Wünsche ohne Regulativ ein Ende. Strategie ist die Kunst des Verzichts, das wird bei AGILE ganz konkret: Das Produktmanagement ist beteiligt, wenn vor jedem Sprint im Backlog die Prioritäten gesetzt werden.

3. Die TECHNIK ist integriert. Der System-Ingenieur ist in vielen Unternehmen eine strategische  Schlüsselfigur, die fachbereichsübergreifendes Wissen (z.B.: Hardware, Software, und Mechanik) verbindet. Die Rolle kann nur von weniger wirklich beherrscht werden. Man hat immer zu wenig davon. Aber wie attraktiv ist die Rolle im Unternehmen? Oft fehlt hierfür der Karriereweg.
Genau dafür gibt es jetzt eine Lösung: die, für viele Unternehmen entscheidende System-Kompetenz bekommt jetzt mehr Sichtbarkeit. Ein Systemingenieur wird zum attraktiven Zielbild für junge, heranwachsende Entwickler, die eine alternative zur Linie-Karriere suchen. Das wettbewerbsentscheidende Know-how der System- und Produktarchitektur wird zu einer persönlichen Verantwortung.

In agilen Framework wird es möglich, den Systemingenieur als Multiplikator für mehrere Projektteams parallel einzusetzen. Damit bekommen mehr Teams bessere Ziele. Das wiederum stärkt die Eigenverantwortung im Team. So kann er Stück für Stück aus der operativen Rolle herauswachsen. Ein sich selbst verstärkender Effekt!

Bevor man sich mit der Schreibweise einer Story befasst, muss das Team verstehen, dass Ziele weit mehr als nur Arbeitsanweisungen sind. Gute Ziele geben dem Team und jedem Einzelnen einen tieferen Sinn und helfen dabei, vorhandene Potenziale voll auszuschöpfen. Sie dienen dazu, einen echten Nutzen für den Product Owner, das Teammitglied und den Kunden zu stiften. Ein gut formuliertes Ziel fördert zudem effiziente Prozesse, schafft den nötigen kreativen Freiraum und formt letztlich einen starken Teamgeist. Damit ein Ziel jedoch verstanden wird, muss von Anfang an klar sein, für wen etwas getan wird, wozu es dient und wie das konkrete Ergebnis aussehen soll.

Um die Güte einer Story zu messen, nutzt man bewährte Frameworks. Das klassische INVEST-Modell nach Bill Wake stellt sicher, dass Stories unabhängig voneinander lieferbar sind und der Umfang verhandelbar bleibt, wobei stets die Intention statt der technischen Umsetzung im Fokus steht. Eine Story muss wertvoll sein, im Aufwand geschätzt werden können und so klein gehalten werden, dass sie weniger als 20 % der Team-Kapazität einnimmt.

Ergänzend dazu macht das „PFUNDIG“-Modell von Stefan Berger eine Story erst richtig rund. Eine pfundige Story ist planbar und umsetzbar, da sie auf den aktuellen Projektstand und die Fähigkeiten des Teams zugeschnitten ist. Sie wirkt fördernd, indem sie das Team aus der Komfortzone lockt, und bleibt dabei stets nützlich und direkt in der Zielansprache. Durch eine individuelle Anpassung an die Situation und eine genaue Definition der Rahmenbedingungen sowie der Akzeptanzkriterien wird sichergestellt, dass keine Missverständnisse entstehen.

In der praktischen Umsetzung geht es darum, Stories so kurz wie möglich zu halten, ohne wesentliche Informationen zu verlieren. Eine pfundige Story beschreibt präzise das erwartete Ergebnis und erklärt das „Wozu“, also wer das Ergebnis nutzt und welchen Zweck es erfüllt. Unverzichtbar sind dabei die Akzeptanzkriterien (Definition of Done), die zeitlich, qualitativ oder quantitativ festlegen, wann eine Story als abgeschlossen gilt.