Product Backlog in aller Kürze
Ich seh schon, der Blog hier kommt deutlich zu kurz. Zeit, mal wieder ein bisschen was zu Papier (oder so) zu bringen. Ich habe mich im letzten Jahr viel mit Lean Engineering und Scrum beschäftigt. Da gibt es natürlich tausend Themen, die auch schon überall sonst beschrieben sind – oder auch nicht? Ich fang einfach mal mit etwas sehr Prägnantem an, den Backlogs und versuche mal eine Beschreibung, wie sie bei uns so ungefähr zutrifft. Vielleicht hilft’s ja dem einen oder anderen.
Product Backlog
Das Product Backlog nach SCRUM ist eine priorisierte Liste all dessen, was für das Produkt benötigt wird. Die Priorisierung der Listeneinträge, der sog. Backlog Items, erfolgt dabei vornehmlich nach dem Kundennutzen; die wertvollsten Einträge stehen oben.
Das Product Backlog wird während der Projektlaufzeit kontinuierlich verändert. Backlog Items werden hinzugefügt, gelöscht, geändert, ersetzt und innerhalb der Liste verschoben, also umpriorisiert. Die Verwantwortung dafür liegt beim Product Owner, einer Person mit einem guten Verständnis für den Kundennutzen und dem Verlangen, diesen zu maximieren.
Die Backlog Items ergeben sich aus der Funktionalen Anylse des Systems und bilden somit die Kundenanforderungen ab. Eine funktionale Anforderung wird als User Story beschrieben, um zu gewährleisten, die Funktionalität aus Benutzersicht zu formulieren.
„Als ein <Rolle> möchte ich <Funktion>, so dass ich <Nutzen>.“
Für Arbeiten, die erledigt werden müssen, aber keinen direkten Kundennutzen erzeugen, werden Technical Stories verwendet. Neben diesen beiden Typen bilden Bugs die dritte Form von Backlog Items im Product Backlog.
Die Stories sind von ihrer Komplexität nur so groß, dass das Team etwa fünf bis fünfzehn in einer Iteration von zwei bis vier Wochen (Sprint) fertigstellen kann. Eine Story, die so groß ist, dass sie nicht in einen Sprint passt, nennt man Epos (Plural Epen; engl. Epic/Epics). Ein Epos wird in mehrere Stories heruntergebrochen. Insofern können Epen also als Feature Sets verstanden werden, die eine Menge von Stories (Features) zusammengehöriger Funktionalität kapselt.
Tooling
Wir nutzen – wie so viele – Atlassian JIRA mit dem JIRA Agile Plugin. JIRA bietet mit Scrum Boards und Kanban Boards zwei Typen von Agile Boards, die sich konfigurieren lassen, eine beliebige Sicht auf eine Menge von Vorgängen abzubilden. Backlogs werden in den Boards durch die Plan- und Arbeits-Ansicht visualisiert.
Das Bild rechts zeigt die Planungs-Ansicht eines Scrum Boards. Die großen Spalte rechts listet alle Backlog Items in Form unterschiedlicher Typen (User Stories, Technical Stories, Bugs), die ihrer Priorität nach geordnet sind. JIRA erlaubt es, die einzelnen Einträge, einfach per Drag & Drop zu verschieben.
In der mittleren Spalte sehen wir die oben angesprochenen Epen, also große Stories. Ein Vorgang in der Liste rechts lässt sich durch Drag & Drop einem Epos zuweisen. Das gleich gilt für die Versionen ganz links, mit denen sich die Release-Planung vornehmen lässt. Einem Vorgang sieht man an, welchem Epos und welcher Version er zugewiesen ist.
Sobald man einen neuen Sprint anlegt, erscheint dieser in der Planungsansicht (Bild oben) über dem Backlog. Vorgänge lassen sich dann dem Sprint durch Drag & Drop zuweisen. Hat man die Planung abgeschlossen, startet man den Sprint und man sieht in der Arbeits-Ansicht den aktuellen Sprint (siehe Bild links). In diesem Beispiel bilden die einzelnen Stories Schwimmbahnen, die die zugehörigen Unteraufgaben gruppieren. Somit bleibt der Fokus für das Team auf dem Abschluss einer Story.
Mit den Spalten Offen, In Arbeit, Erledigt kann das Team im Daily Scrum den Fortschritt verfolgen. Zudem erlaubt es JIRA, Schnellfilter zu definieren, mit denen sich Vorgänge ausblenden lassen; siehe etwa den Schnellfilter „Nur meine Vorgänge“ im Screenshot, der nur die Vorgänge des eingeloggten Benutzer zeigt.