Die nächsten Schritte vor Augen dank Product-Backlog-Board

Bei //SEIBERT/MEDIA arbeiten wir in externen und internen Projekten bevorzugt mit agilen Vorgehensmodellen und Methoden und haben die Vorteile der Zusammenarbeit in Teamräumen mit Visualisierung der wichtigsten Artefakte erkannt. Alle unsere Büros verfügen über Taskboards, auf denen die Teams ihre aktuell anfallenden Aufgaben verwalten und in täglichen Standup-Meetings besprechen, was als nächstes zu tun ist.

Der Fokus des Taskboards liegt dabei auf den Arbeiten, die in den nächsten Tagen oder Wochen abgeschlossen werden sollen. Bei Scrum-Teams ist es der aktuelle Sprint, der dargestelt wird. Was ist aber mit den Aufgaben, die in den nächsten Wochen oder Monaten anstehen? Was hat das Team also mittelfristig zu tun?

Transparenz über mittelfristige Arbeiten: Das Product-Backlog-Board

Wenn in Projekten längerfristig gearbeitet wird – beispielsweise an komplexen Software-Produkten -, empfiehlt sich die Etablierung eines Product-Backlog-Boards.

Zur Erinnerung: Was war noch gleich ein Product Backlog? Grundsätzlich enthält das Product Backlog alle Arbeiten, die zur Erstellung eines erfolgreichen Produkts notwendig sind. Konkret handelt es sich dabei z.B. um neue Funktionalitäten, einfache Aufgaben oder Fehlermeldungen, die das Team zu bearbeiten hat.

Das Product-Backlog-Board ist eine Visualisierung dieses Product Backlogs und der wichtigsten Constraints (= Nebenbedingungen/Auflagen) im Teamraum, sodass sich alle Teammitglieder und auch die Stakeholder jederzeit darüber informieren können.

Der Aufbau eines Product-Backlog-Boards

Den grundlegenden Aufbau eines Backlog Boards erläutert Roman Pichler in seinem Artikel The Product Backlog Board. Die folgende Darstellung zeigt ein reduziertes Board, an dem auch wir uns orientieren:

product-backlog-board

Die zentralen Bereiche des Product-Backlog-Boards sind die Story Area und die Constraint Area.

Die Story Area

In der Story Area wird das Product Backlog der aktuell in Arbeit befindlichen Version vorgehalten. Es handelt sich dabei nicht zwangsläufig um sauber ausformulierte User-Stories, sondern oft auch um Fehlermeldungen und entdeckte Bugs.

User-Stories sind in drei Granularitätsgraden integriert: Stories, Epics und Themes.

Fein zerteilte Stories, die bereit für die Umsetzung sind, befinden sich oben im Bereich Ready items. Die feine Zergliederung wird dabei vornehmlich für die hochprioren Stories vorgenommen, die nach Möglichkeit im nächsten Sprint eingeplant werden sollen.

Im unteren Teil der Story Area befinden sich Themes und Epics. Die Themes dienen zur ganz groben Unterteilung des Backlogs nach Themenbereichen. Die Epics sind grobe Formulierungen von Features, die erst dann feiner formuliert und ausgearbeitet werden, wenn die Umsetzung naherückt.

Im Bereich der Ready items ist eine Priorisierung durch den Product Owner Pflicht, während sie nach Pichler im Bereich der Themes & Epics nicht unbedingt erforderlich ist.

Die Constraint Area

In der Constraint Area werden die grundlegenden Anforderungen an die Oberfläche der Software sowie operative Eigenschaften der Anwendung festgehalten.

Das Produkt- und User-Interface-Design kann z.B. in Form von Screenshots, Wireframes und selbst einfachen Skizzen mit Anmerkungen zu den wichtigsten Vereinbarungen dargestellt werden.

Die operativen Eigenschaften lassen sich mithilfe von Constraint Cards abbilden, wobei das Team pro Karte eine bestimmte operative Eigenschaft festhält, beispielsweise die Browser, für die das System zu optimieren ist, die Performance der Software, die Skalierbarkeit usw.

Dabei ist es ratsam, die Constraints mit der Definition of Done zu verknüpfen, damit deren Einhaltung zum Bestandteil der Abnahme jeder einzelnen User-Story wird. Das lässt sich gut am Beispiel der Browser-Optimierung verdeutlichen: Wird diese in die Definition of Done aufgenommen, ist bei der Abnahme einer Story auch eine entsprechende Prüfung in den verschiedenen Browsern vorzunehmen. Ist die Erfüllung dieses Constraints nicht gegeben, gilt die Story auch nicht als "Done".

Regelmäßige Backlog-Pflege

Die regelmäßige Pflege des Product Backlogs und des Boards erfolgt in Form von Backlog-Grooming-Workshops oder -Sessions. Das Team (inkl. Product Owner) nimmt dabei gemeinsam eine Aktualisierung des Backlogs vor, bespricht Stories, zerteilt sie, fügt neue hinzu und beschätzt sie.

Für Teams mit zweiwöchigen Sprints gilt als Faustregel, zwei Stunden pro Woche mit Backlog-Grooming-Workshops zu verbringen, was 5% der Arbeitszeit einer 40-Stunden-Woche entspricht. Diese Zeit ist gut investiert: Das Team erfährt frühzeitig, was demnächst zu erwarten ist, kann selbst Vorschläge einbringen, Lösungsoptionen können erarbeitet, Risiken für die Umsetzung frühzeitig erkannt und adressiert werden.

Der Beitrag des Teams zur Erstellung und Pflege des Backlogs wird damit deutlich größer und die Qualität des Backlogs nimmt erfahrungsgemäß signifikant zu.

Product-Backlog-Board und Software-Unterstützung

Und wie steht es mit der Nutzung elektronischer Hilfsmittel, wenn ein Product Backlog Board erstellt und gepflegt wird? Wir arbeiten mit der professionellen Aufgabenmanagement-Software JIRA und pflegen unseren Backlog in diesem System. Über ein Scrum Cards Plugin können wir kompakte Ausdrucke der Zettel vornehmen, die wir sowohl für unsere Product-Backlog-Boards als auch für die Taskboards nutzen. So können wir die Vorteile elektronischer Systeme und die Vorteile der präsenten Offline-Darstellung mit geringem Mehraufwand verbinden.

Haben Sie Fragen zu agilen Vorgehensweisen? Möchten Sie Agilität in Ihrem Unternehmen einführen? Bei //SEIBERT/MEDIA ist “Agile” in Projekten an der Tagesordnung. Mit mehr als 20.000 Stunden Projekterfahrung in internen und externen Projekten mit agilen Entwicklungsmethoden gehört //SEIBERT/MEDIA zu den erfahrenen und größten Anbietern für Scrum in Verbindung mit den Atlassian-Tools JIRA/Greenhopper und Confluence in Deutschland. Gerne helfen wir Ihnen bei der Etablierung agiler Prinzipien und Verfahren – sprechen Sie uns einfach unverbindlich an.

Ausführliche Informationen zu unseren Agile-Dienstleistungen finden Sie in unserem Agile-Orientierungsangebot mit Leistungsbeschreibungen und Beispielkalkulationen.

Weiterführende Informationen zur Backlog-Pflege

User-Stories: Anforderungen aus Nutzersicht dokumentieren
Card, Conversation, Confirmation: Die drei Cs einer User-Story
User-Stories schreiben ist wie Fahrradfahren
Die besten Ressourcen zu User-Stories

Dieser Artikel wurde in ähnlicher Form am 13. Juli 2011 im Blog Produktmanager-Internet.de unter dem Titel Das Product Backlog Board von Paul Herwarth von Bittenfeld veröffentlicht. Paul Herwarth von Bittenfeld arbeitet seit 2003 bei //SEIBERT/MEDIA und für die Tochtergesellschaften Gartentechnik.com, TwentyFeet und naturkostaktiv. Weitere Fachartikel des Autors finden Sie in unserem Special Produktmanagement.


Mehr über die Creative-Commons-Lizenz erfahren