In der Deutschen Fassung des Scrum Guide von Jeff Sutherland und Ken Schwaber steht an erster Stelle im Abschnitt Produkt Backlog das Folgende:
„Das Product Backlog ist eine geordnete Liste von allem, was in dem Produkt enthalten sein kann. Es dient als einzige Anforderungsquelle für alle Änderungen am Produkt.“
Und damit ist bereits vieles klar, dass es sich um tatsächlich DIE eine Liste der Anforderungen für das Softwareprodukt handelt. Dort werden alle Aspekte wie Features, Funktionalitäten, Verbesserungen und Fehlerbehebungen niedergeschrieben. Es dient also tatsächlich als Zentrales Werkzeug um den Leistungsumfang eines Softwareproduktes zu definieren und „im Auge“ zu behalten. Ein Produkt Backlog muss daher ein lebendes Gebilde sein, in das die Anforderungen an das Softwareprodukt aufgenommen und verwaltet werden.
Als Product Backlog eignen sich einfache Listen in Form von Word oder Excel Dokumenten. Im Grunde gilt hierbei: Je einfacher das Medium in der Handhabung ist, umso leichter lässt es sich im ersten Schritt etablieren.
Innerhalb eines Product Backlogs nennt man die einzelnen Einträge User Stories. Unter einer User Story versteht man quasi eine kleine Geschichte die den Leistungsumfang des Features oder Funktion darstellt. Zu jeder User Story muss ein gewisser Informationsumfang ermittelt und niedergeschrieben werden. Was genau in einer User Story alles festgehalten werden sollte, habe ich ausführlich betrachtet und das kann man in einem eigenen Artikel nachlesen.
Das Produkt Backlog sollte in erster Linie eine Übersicht sein, in der die einzelnen User Stories dargestellt werden. Die interessanten Spalten eines Product Backlogs können in jeder Scrum Implementierung variieren. Letztendlich kann man aus meiner Sicht die Aussagekraft eines Product Backlogs auf die folgenden Punkte reduzieren:
- Welche User Stories gibt es überhaupt?
- Wie ist der Status einer User Story?
- Wie viel Aufwand ist es die User Story umzusetzen?
- Was soll eine User Story wirklich leisten?
- Wann wird eine User Story implementiert?
Wenn man im Unternehmen bereits ein Softwarewerkzeug für das Management von Anforderungen verwendet, sollte man ruhig darüber nachdenken auf dieser Plattform das Product Backlog aufzusetzen. Man muss ja davon ausgehen, dass der betroffene Personenkreis im Umgang mit dem Tool bereits routiniert ist und lediglich eine neue Darstellungsform der einzelnen Anforderungen annehmen muss.
Aus meiner Erfahrung empfehle ich generell für das Management der Anforderungen leicht zu starten und erst in einer weiteren Iteration ggf. auf ein Tool umzuschwenken. Man sollte immer im Kopf behalten, dass man sich nicht mit aufwendigen Verwaltungsprozessen und stundenlangen Eingaben die Agilität wieder kaputt macht. Im Falle dass man bereits Scrum im Unternehmen „eingeführt“ hat und man sich nun an der Stelle steht die Verwaltung auf ein elektronisches Tool umzuschwenken, sollte man sich über die Anforderungen an das Softwarewerkzeug bewusst werden.
Bei der Auswahl eine Softwaretools sollten nicht nur fachliche sondern auch Systemische Aspekte betrachtet werden:
- Welche Technologie Plattform kann ich der Internen IT für den Betrieb abverlangen
- Welche Schnittstellen zu korrespondierenden Systemen sind vorhanden
- Muss das System einem Externen Personenkreis (Remote) zur Verfügung stehen
- Welche Sprachen müssen unterstützt werden
- Muss ein Berechtigungskonzept beachtet werden und müssen dadurch Rollen innerhalb des Softwarewerkzeugs abgebildet werden
Bei der Auswahl des Tools für das Anforderungsmanagement kann ich aus dem Bereich Opensource Software „the bug genie“ herausdeuten. Der Name des Softwareproduktes ist in diesem Zusammenhang etwas verwirrend. Bei „the bug genie“ dreht es sich klar um Bug Tracking, aber die inkludierten Features zum Projektmanagement sind sehr ausgeprägt. Man kann auf eine flexible Scrum Implementierung, Workflow Engine, Wiki und andere Projektmanagement Features zurückgreifen. Ich habe „the bug genie“ mal im Bezug auf die Scrum Implementierung etwas genauer betrachtet, und hierzu einen Artikel geschrieben.