Seite 2: Product Owner

Inhaltsverzeichnis

Werkzeug für Produkt-Manager

Der Product Owner sollte mit Agilo in der Lage sein, alle wichtigen Aufgaben durchzuführen. Das sind vor allem folgende Punkte wie [2]:

• Anforderungsmanagement
• Planung
• Priorisierung
• Kommunikation
• Budget
• Return on Investment

Er hält die Anforderungen priorisiert im Product Backlog fest. Das Wie schreibt Scrum nicht vor, sondern es bezeichnet sie dort nur als Backlog-Items. Es ist jedoch gängige Praxis, Anforderungen in Form von sogenannten User Stories zu beschreiben [3]. Dabei besteht eine User Story aus einem kurzen Text, der aus der Sicht eines Benutzers des zu entwickelnden Produkts geschrieben ist. Neben der Information, welche Rolle der Benutzer hat (Admin, allgemeiner Benutzer, privilegierter Benutzer ...), beschreibt sie eine bestimmte Aktion und den Mehrwert der Aktion für den jeweiligen Benutzer. Doch wann weiß der Entwickler des Produkts, dass die Arbeit an der User Story abgeschlossen ist? Dafür sind sind Akzeptanzkriterien und die "Definition of Done" zu berücksichtigen.

Die Akzeptanzkriterien lassen sich in der jeweiligen User Story festhalten und beschreiben konkrete Ergebnisse, Verhaltensweisen oder Ähnliches, was der Product Owner erwartet. Sind die Kriterien erreicht, ist die User Story aus fachlicher Sicht erledigt. Es gibt jedoch noch Dinge wie das Einchecken des Quellcodes in das Versionskontrollsystem, der Review eines Kollegen, das erfolgreiche Durchführen aller Tests des Softwaresystems, die nicht spezifisch für eine User Story sind, sondern übergreifend gelten. Scrum-Teams halten sie in den sogenannten Definitions of Done fest. Agilo unterstützt ein solches Vorgehen. Anforderungen lassen sich in zwei Formen aufnehmen – über Requirements und User Stories.

Requirements stellen eine Art abstrakte Anforderung dar, deren Konkretisierung die User Stories ausdrücken (siehe Abbildung 3). Um als Product Owner ein neues Requirement in Agilo anzulegen, sind neben der Beschreibung des Requirements auch der Stakeholder und der Geschäftswert (Business Value) wichtig. Durch diese ist es einfach abzubilden, welchen Mehrwert ein Requirement nach Fertigstellung hat und was das für das Projekt bedeutet. Mit dem Stakeholder kann der Product Owner festhalten, wer ein Interesse an dem Requirement hat, auch ziehen sie den Geschäftswert zur Priorisierung heran. Agilo unterstützt hier die numerischen Werte des Business-Value-Spiels. Der Product Owner hat als einzige Rolle das Recht, Requirements anzulegen.

Das gilt auch für User Stories. Wichtig ist in dem Fall die Priorität der User Story. Agilo unterstützt hierbei das Kano-Modell, nach dem folgende Prioritäten vorhanden sind:

• Mandatory: absolutes Muss
• Linear: Je mehr sich von ihnen realisieren lassen, desto besser.
• Exciter: kann, muss aber nicht. Hat eher einen "Wow"-Effekt.

Der Product Owner gibt in Agilo die User Stories in einem Freitextfeld ein. Dabei wird das oben genannte Format der User Story nicht überprüft, was dazu führen kann, dass User Stories gegebenenfalls umständlich und schwer verständlich sind. Ebenfalls gibt es keine Eingabemöglichkeit für die Akzeptanzkriterien. Was verwundert, ist die Option, User Stories zuweisen zu können, da der Product Owner nach Scrum das nicht darf.

Für die Definition of Done lässt sich das Wiki benutzen (siehe Abbildung 4). Leider sortiert Agilo die Einträge des Product Backlog nicht automatisch nach Priorität, sodass man selbst Hand anlegen muss. Glücklicherweise kann das per Drag & Drop erfolgen, sodass der Product Owner seine bevorzugte Reihenfolge schnell herstellen kann.

Wie man es aus den traditionellen Vorgehensweisen her kennt, lässt sich auch in Agilo ein Meilensteinplan anlegen – die sogenannte Roadmap. Sie dient dazu, den roten Faden durch das Projekt zu visualisieren. Dabei gibt es ein oder mehrere markante Punkte, die einen signifikanten Funktionsanstieg markieren, sogenannte Zwischenziele oder Meilensteine. Jeder Meilenstein lässt sich mit einem Namen und einer Beschreibung versehen, was für die Entwickler gut ist, da immer klar ist, was das Ziel der Arbeit ist, auf das man hin arbeitet. Für eine übergreifende Produktvision kann man wiederum das Wiki verwenden.

In Scrum erfolgt die Entwicklung iterativ. Iterationen heißen Sprints. In einem Sprint setzt das Entwicklerteam im Allgemeinen mehrere User Stories um. Sprints lassen sich Meilensteinen zuweisen. Da Scrum-Teams User Stories in Agilo als erledigt markieren können, kann man über den Meilensteinplan nachvollziehen, wie der Fortschritt ist. Dabei werden jedoch keine verbleibenden Stunden berücksichtigt, sondern Aufgaben und User Stories. Auf ihre Beziehungen zueinander sei später eingegangen.

Somit kann man mit Agilo den Projektfortschritt im Auge behalten. In der tabellarischen Übersicht des Product Backlog finden sich mehrere Punkte zu den Anforderungen, die Agilo automatisch berechnet, und zwar Return on Investment und User Story Points. Die User Story Points eines Requirements sind die Summe aller Punkte der mit einer Anforderung durch Link verbundenen User Stories. Der Wert für den Return on Invest ist direkt aus der Oberfläche abzulesen. Die Summe am unteren Ende der Tabelle gibt Auskunft, wie viele Punkte man insgesamt umgesetzt hat (inklusive der abgearbeiteten Requirements).

Bei der Arbeit mit Agilo muss man sich eine Tatsache vor Augen halten: das Product Backlog enthält nur Einträge, die noch nicht geplant sind. Sobald ein Eintrag des Product Backlog zugewiesen wurde, verschwindet er aus dem Backlog. Die Einträge lassen sich den jeweiligen Sprint Backlogs entnehmen. Wer eine Übersicht über die fertiggestellten Einträge haben möchte, kann hierfür ein weiteres Artefakt oder Backlog anlegen.

Eine Releaseplanung unterstützt Agilo nicht direkt. Zwar kann man mit den Meilensteinen relativ weit kommen, aber es fehlt die Berücksichtigung der Velocities. Diese geben an, wie viele Story Points ein Team in einem Sprint umsetzen konnte. Die Verwaltung des Budgets, für das der Product Owner in vielen Fällen zuständig ist, berücksichtigt Agilo nicht. Zu den eher klassischen Managementfähigkeiten, die der Product Owner ebenfalls mitbringen sollte, wird in Scrum nicht viel gesagt und somit geht das über die Produktvision eines Werkzeugs zur Unterstützung von Scrum hinaus. Hilfreich wäre es dennoch. So muss der Product Owner auf andere Hilfsmittel ausweichen. Hinsichtlich der Kommunikation gibt es für ihn allerdings nur die aufgezeigten Mittel.

Abschließend lässt sich sagen, dass der Product Owner eine gute Unterstützung für die in Scrum ihm zugewiesenen Aufgaben durch Agilo erhält. Er ist für das Product Backlog verantwortlich, hat demnach auch nur die Möglichkeit, dieses samt Einträgen zu verwalten. Das Verhalten lässt sich jedoch ändern, wobei das mit Vorsicht zu genießen ist und man sich immer fragen sollte, warum man das will und ob es nicht eventuell einen Bruch mit Scrum darstellt. Daneben gibt es die Verwaltung der Meilensteine, was jedoch nicht Scrum-spezifisch ist.

Negativ fällt auf, dass der Product Owner standardmäßig nicht berechtigt ist, Fehler zu melden. Es sollte jeder, der in den Entwicklungsprozess eines Softwareprojekts involviert ist, in der Lage sein, Feedback zu melden. Hier lassen sich aber Agilos umfassende Konfigurationsoptionen nutzen, um dem Product Owner diese Rechte einzuräumen.