Motivation

Als Product Owner*in (PO) in agilen Entwicklungsprojekten gibt es nach all den theoretischen Vorstufen irgendwann den Punkt, an dem aus einer Idee etwas Greifbares wird. Endlich kann man sehen und nutzen, was man oft lange mit Stakeholdern und Entwicklern besprochen und ausgefeilt hat.
So schön dies für den/die PO auch sein mag, merkt man doch auch öfters die Vorbehalte der Entwickler*innen. Oft haben die Artefakte (hier: „Storys”) schon einige Qualitätskontrollen durchlaufen und nun muss auch noch der/die PO draufschauen? Was soll der/die PO denn noch finden? Die Akzeptanzkriterien sind doch eindeutig definiert und wurden sorgfältig beachtet.
Die Wirklichkeit zeigt allerdings, dass sich die PO Abnahme trotzdem häufig lohnt. In diesem Artikel möchte ich den Prozess etwas näher beleuchten und einige Good Practices zu einer effizienten PO Abnahme geben. Dabei gehe ich immer von agilen Entwicklungsmethoden (insbesondere Scrum) und autonomen Teams aus, wobei der/die PO zwar die Interessen der Stakeholder vertritt, aber in hohem Maße legitimiert ist Storys abzunehmen.

Einleitung

Die PO Abnahme bettet sich wie folgt in einen beispielhaften Entwicklungsprozess ein: Wir starten im Sprint X-1. Hier werden in den Refinements und dem Planning die Storys besprochen, die das Team plant in Sprint X umzusetzen. Im Laufe der Zeit erreichen die Storys die „Definition of Ready (DoR)” womit sie ihre Eintrittskarte für das Sprint Backlog erhalten (welche Storys dann letztlich verplant werden, ist ein anderes Thema).

Nehmen wir eine Beispielstory (hier: POA-1), damit es etwas plastischer wird. 

Beschreibung:

Als Mitarbeiter bei tarent
möchte ich online eine Gehaltserhöhung beantragen,
so dass ich im nächsten Jahr mehr Geld verdiene.

…und Akzeptanzkriterien (AKs):

1. Die gewünschte Gehaltsanpassung darf auf einer Maske im System XY eingegeben werden
2. Es darf nur ein Wunsch pro Jahr eingegeben werden
3. Der Wunsch muss in Prozentwerten angegeben werden
4. Der Wunsch durchläuft eine Statuskette
5. Der Gehaltswunsch darf nur von speziell berechtigten Personen eingesehen werden

Hinweis: Bitte nicht zuuu stark darüber nachdenken, ob das eine tolle Story ist oder ob man sie nicht vielleicht splitten sollte, umformulieren müsste, etc. 🙂 

Da diese Anforderung natürlich ultra wichtig ist, schafft sie es in den Sprint X. Dann startet Sprint X und das Sprint Backlog wird abgearbeitet. Auch unsere Story POA-1 wird direkt angegangen. Nach ca. einer Woche sind die Entwickler zufrieden mit dem Ergebnis. Alle Punkte der „Definition of Done (DoD)”, die auf das Entwicklungsteam entfallen sind, sind erledigt. Jetzt fehlt nur noch die Abnahme durch den/die PO. Also erhält das Ticket den entsprechenden Status.

Warum eigentlich?

Betrachten wir diese Übergabe etwas genauer: Da hat ein*e erfahrene*r Entwickler*in mehrere Tage mit der Entwicklung verbracht. Hat geflucht, gegoogelt und sich bei Kollegen*innen und vielleicht sogar bei dem/der PO (!) Rat geholt.
Nun sind alle Tests grün, es gibt keine Merge-Konflikte mehr und die Welt könnte sich weiter drehen. Man hätte endlich einen Haken an dieser Story und könnte sich der nächsten zuwenden, ohne erwarten zu müssen, dass das Ticket nochmal zurück kommt. Denn, sind wir mal ehrlich, alles was jetzt noch kommt, können ja nur noch „Change Requests (CRs)” sein, oder?
Vielleicht hat auch der Akt der Abnahme für manche Entwickler*innen etwas Hierarchisches und Bevormundendes.

Die Abnahme

Für mich selbst (und viele andere POs) ist die jungfräuliche Abnahme einer Story der schönste Teil meines Jobs! Nicht aus den antizipierten Gründen des letzten Kapitels, sondern aus einer kindlichen Lust am Entdecken.
Bei manchen Storys fragt man sich ja schon bei der Definition der Akzeptanzkriterien: „Wie das wohl umgesetzt wird?”. Umso größer dann die Entdeckungsfreude!
Aber Schritt für Schritt: Die Story POA-1 wechselt in einen Status á la „PO Abnahme”.

Good Practice 1: Stürzt euch sobald wie möglich auf die Story und plant genügend Zeit ein!

Nur wenn man Probleme zeitnah erkennt, kann man sie evtl. auch noch innerhalb des Sprints beseitigen; außerdem soll man ja das Eisen schmieden solange es noch heiß ist, sprich, der/die Entwickler*in noch weiß, was er/sie getan hat.
Allerdings ist man als PO häufig terminlich eingebunden. Wenn es nicht gerade eine sehr triviale Story ist, sollte man diese nicht zwischen zwei Termine quetschen, sondern sich mindestens eine halbe Stunde Zeit nehmen. Wie oben beschrieben, hat sich hier jemand viel Mühe gegeben und das sollten wir bei der Abnahme auch tun. Einerseits für die Qualität unserer Abnahme, andererseits aber aus Respekt und einem professionellen Miteinander!
Solltet ihr trotz allem kurzfristig keinen ausreichenden Zeitslot finden, nehmt euch zumindest ein paar Minuten Zeit für einen Smoketest. Ich habe es selbst schon so häufig erlebt, dass man direkt auf einen Blocker stößt, der den ganzen Test unmöglich macht. Dies frühzeitig und nicht erst kurz vor dem Sprint Review festzustellen ist wirklich Gold wert!

Der/die PO sieht die Notification des Ticketsystems voller Freude, macht noch schnell die bereits angefangene Mail fertig und nimmt die Abnahme dann in Angriff. Zum Einstieg empfiehlt es sich, die Story und die AKs zu lesen, um wieder im Thema zu sein. Arbeitet man nach Prinzipien des Test Driven Developments (TDD) und hat im vorhinein Testfälle definiert, können diese zunächst außer acht gelassen werden.

Good Practice 2: Missachtet die Story-Kommentare!

Alles, was sich nicht in der Story-Beschreibung und den AKs wieder findet, ist nicht relevant! Es kommt durchaus vor, dass es während der Entwicklung eine Notwendigkeit gibt diese anzupassen. Aber wenn dies nicht im Zusammenspiel zwischen Entwickler*in und PO geschieht, sind die Diskussionen dazu nur Schall und Rauch. „Im Kommentar vom 16.11.2021 um 11:23 haben wir aber gesagt, dass…” Nein! Egal!
Das kann zwar dazu führen, dass es am Anfang etwas knirscht, aus meiner Erfahrung heraus, steigert es aber langfristig die Verbindlichkeit auf beiden Seiten.

Nun also los: Einloggen im System und Eingabemaske aufrufen. Hm, wo ist die nur? Hab ich vielleicht keine Berechtigung? Jetzt also doch ein Blick in die Story-Kommentare. Scroll, scroll…ah, Seite X und Tab Y, gefunden! Jetzt die Eingabe in Prozent, funktioniert!…
Und so geht das explorative Testen weiter bis man entweder auf einen Blocker stößt oder alle AKs validiert hat.
Bei einer so komplexen (und lückenhaft beschriebenen) Story wie POA-1 gibt es mit Sicherheit Dinge nachzuarbeiten. Deren Gründe kann man grob einteilen in

1. Klare Verletzung der AKs
2.Unzufriedenheit des/der POs mit unspezifizierten Verhalten (hier: Anordnung der Eingabemaske)
3. Unzufriedenheit des/der POs mit spezifizierten Verhalten (hier: Eine einzelne Eingabe pro Jahr kann zu wenig sein, wenn der Gehaltswunsch abgelehnt wird)

Durch das Wort „Unzufriedenheit” schießt einigen Entwickler*innen an dieser Stelle sicherlich der Puls in die Höhe, aber bitte beachtet Folgendes: Es existiert zwar eine (möglichst präzise) Beschreibung der Anforderung, aber letztlich folgen wir dem agilen Manifest. Darin werten wir u.a. die „working software” höher als „comprehensive documentation”. Working software wird zwar erdacht/spezifiziert, muss sich aber letztlich in der eigentlichen Nutzung des Systems erst noch beweisen. Dabei ist der/die PO nur der/die erste von sehr vielen Kritikern. Und was es bedeutet, wenn Unzulänglichkeiten erst spät entdeckt werden, wurde schon in unzähligen Studien beschrieben.
Das soll nun bitte nicht als Freibrief für den/die PO verstanden werden, dass er/sie letztlich willkürlich entscheidet. Ich möchte damit nur ausdrücken, dass die Punkte 2 und 3 durchaus ernstgenommen werden müssen. Je nach Aufwand sollte man ausloten, ob eine Anpassung innerhalb der Story noch möglich ist oder ob es einer weiteren Story für einen Folgesprint bedarf.

Good Practice 3: Offen über alle Ergebnisse sprechen, und ggf. ein Pair-Review machen.

Insbesondere bei größeren Storys wie unserer POA-1 macht es meistens Sinn gemeinsam die Main-User Flows durch zu gehen. Der/die Entwickler*in erhält dadurch auch die Gelegenheit gewisse Design-Entscheidungen für Spezifikationslücken zu erläutern. Vielleicht macht es danach durchaus Sinn, dass die Eingabemaske dort ist, wo sie ist und der Kommentar/Bug muss gar nicht mehr  geschrieben werden
Die Story geht also zurück in die Entwicklung, wird überarbeitet, kommt wieder zum Review und wird schließlich abgenommen. Am Ende von Sprint X steht nun das Review mit den Stakeholdern an. Durch das frühzeitige und intensive Review mit dem/der PO lauern hier keine Gefahren mehr und das Team kann wirklich als solches geschlossen auftreten. Anmerkungen, die nun kommen, werden immer noch gerne genommen, die Chancen stehen aber gut, dass diese nicht gravierend sein werden.

Fazit

Ist eine PO Abnahme also immer erforderlich und sinnvoll? Das ist sicher nicht der Fall, denn viele Entwicklungsergebnisse kann der/die PO gar nicht feststellen und bewerten. Schlimmer noch: Die Entwickler*innen könnten sich dadurch gegängelt fühlen. Hier ist es an dem jeweiligen Team geeignete Prozesse zu etablieren.
Aber alles was direkte Auswirkungen auf User haben wird, sollte genau durch den/die PO getestet und abgenommen werden. Es geht nicht darum, dass die Qualitätsmaßnahmen vorher zwecklos sind oder der/die PO sich profilieren will, sondern es geht darum ein gutes Produkt zu entwickeln. Und das gelingt nicht allein durch Spezifizieren und maschinelle Tests, sondern insbesondere durch manuelle Interaktion mit dem System.