Erstellen und Verwalten des Produktrückstands

Artikel
06/10/2015

Von Mitch Lacey. Besitzer von Mitch Lacey & Associates, Inc, einem auf Agile- und Scrum-Umsetzungen und -Optimierungen spezialisierten Beratungsunternehmen.

Januar 2012

In diesem Artikel erklärt Mitch Lacey die Bedeutung eines Product Backlogs und beschreibt, was ein gutes Backlog ausmacht. Zudem stellt er einige bewährte Vorgehensweisen zum Erstellen und Verwalten des Backlogs vor.

Betrifft

Application Lifecycle Management; Team Foundation Server (TFS)

In diesem Artikel:

Einführung
Product Backlog
- User Storys
- Schätzen
- Priorisieren
Dynamisches Product Backlog
- Grooming

Ein Product Backlog ist eine priorisierte Liste aller Features und Funktionen, die für den Abschluss eines Projekts erforderlich sind. In TFS verwalten Sie den Produktrückstand mithilfe von Arbeitsaufgaben. Die Wahl der Arbeitsaufgabentypen variiert je nach Prozessvorlage, die zum Erstellen des Teamprojekts verwendet wurde. Weitere Informationen zu Prozessvorlagen und den Arbeitsaufgabentypen, die sie unterstützen, finden Sie unter Arbeiten mit Teamprojektartefakten, Auswählen eines Prozessleitfadens.

Ein gutes Product Backlog ist die Grundlage für ein gut funktionierendes Agile-Team und weist folgende Merkmale auf:

Durch die Priorisierung wird sichergestellt, dass das Team die wichtigsten Features zuerst erstellt.
Das Product Backlog wird vom Team geschätzt, um dem Product Owner Klarheit zu verschaffen und ihm zu ermöglichen, Fragen, z. B. nach dem Zeitpunkt der Fertigstellung dieser Storys, zu beantworten.
Es enthält alle für den Abschluss des Projekts notwendigen Aufgaben.
Es ist ein dynamisches Dokument, das ständig geändert und weiterentwickelt wird, um die aktuellen Gegebenheiten des Projekts widerzuspiegeln.

Ein gutes Product Backlog ist zwar keine automatische Garantie für gute Software, das Fehlen eines guten Product Backlogs hat jedoch oft eine unvollständige Software zur Folge, die nicht den Anforderungen Ihrer Kunden und Stakeholder entspricht.

Die Verwaltung des Product Backlogs ist eine Vollzeitaufgabe. Einfache Techniken können dabei helfen, einen anscheinend überwältigenden und zeitraubenden Prozess in einen interaktiven, iterativen Vorgang umzuwandeln, an dem Teammitglieder, Kunden und Stakeholder effektiv beteiligt sind. Es ist daher äußerst wichtig, dass Sie solide Techniken für die Erstellung, Priorisierung und Verwaltung des Product Backlogs erlernen.

Product Backlog

Das Product Backlog ist eine priorisierte, dynamische Hauptliste aller Features und Funktionen, die für den Abschluss eines Projekts erforderlich sind. Product Backlogs enthalten in der Regel Anforderungen, User Storys (z. B. Anforderungen), Fehler, Forschungsaufgaben (Spitzen) und technische Verbesserungen. Diese Einträge werden in abstrakten Einheiten bewertet, die oft als Storypunkte bezeichnet werden.

Product Backlogs umfassen alle Aufgaben, die für das Projekt erforderlich sind, und werden stetig weiterentwickelt. Aus diesem Grund sind nicht nur die neuen Features eines Produkts enthalten, sondern auch Fehlerkorrekturen und Forschungsarbeiten, d. h. alles, was mit einem zeitlichen Aufwand für das Team verbunden ist. Die gesamte Arbeit, die vom Team ausgeführt wird, muss seinen Ursprung im Product Backlog haben: Das Product Backlog ist sozusagen das Eingangstor zum Projekt. Wenn das Product Backlog alle Aufgaben enthält, haben der Product Owner, das Team und das Management eine bessere Vorstellung von der noch zu erledigenden Arbeit. Unangenehme Überraschungen in letzter Minute werden somit vermieden.

Am Anfang eines Projekts ist es unwahrscheinlich, dass bereits eine vollständige Liste genauer, gut definierter Product Backlog-Einträge für die Schätzung und Priorisierung vorhanden ist. Stattdessen werden wohl eher einige Notizen für User Storys und vielleicht ein oder zwei Funktionsspezifikationen vorliegen. Als Product Owner ist es Ihre Aufgabe, dieses Chaos in eine geordnete Form zu bringen, damit das Team mit der Schätzung des Backlogs beginnen kann.

User Storys

Der erste Schritt besteht darin, alle Ideen und Notizen in User Storys umzuwandeln, die die vom Endbenutzer gewünschte Funktionalität zum Ausdruck bringen (d. h. das, was die Software machen soll). Um die Implementierungsdetails (d. h., wie die Software erstellt wird, die diese Anforderungen erfüllt) geht es hier nicht. Der Titel jeder User Story sollte folgendem Format entsprechen: “Als <Benutzer> möchte ich <Funktionalität>, damit <Grund>”.

Beispiel für eine Story Card

So wie das Product Backlog werden User Storys ebenfalls stetig weiterentwickelt. Im Laufe des Projekts wird das Team diese Storys priorisieren und schätzen, ausführliche Informationen hinzufügen und in kleinere Storys unterteilen oder ganz löschen. Die Storys die in Sprints übertragen werden, werden implementiert und an den Kunden geliefert.

Weitere Informationen zu User Storys finden Sie unter Erstellen Ihres Backlogs und Storyboarding von Ideen mit PowerPoint.

Nachdem alle Ideen und Notizen in User Storys umgewandelt wurden, ist es Zeit für die Schätzung und Priorisierung.

Schätzen

Schätzen ist definitionsgemäß ungenau. Mit ein wenig Zeit, Übung und der Beteiligung des gesamten Teams können Sie jedoch relativ genaue Schätzungen erstellen. Der erste Schritt besteht darin, das Team zusammenzuführen, um Schätzungen zu den Product Backlog-Einträgen abzugeben. Wenn das Team eine Story schätzt, geben Sie eine relative Größenschätzung mit einer abstrakten Maßeinheit, einem Storypunkt, ab.

Schätzungen sind aus zwei Gründen von grundlegender Bedeutung:

Sie helfen bei der Beantwortung der Frage nach dem Zeitpunkt der Fertigstellung.
Sie helfen dem Product Owner bei der Priorisierung der einzelnen Einträge.

Schätzungen vermitteln dem Product Owner und dem Team eine Vorstellung von den Kosten einer bestimmten Story, was wiederum dem Product Owner hilft, die Storys relativ zueinander zu priorisieren. Je höher die Schätzung eines Eintrags ist, desto kostenintensiver wird die Implementierung hinsichtlich des Zeit- und Ressourcenaufwands. Ein Eintrag, der beispielsweise ganz oben auf der Wunschliste des Product Owners stand, kann deshalb an Priorität verlieren, wenn die Kosten zu hoch sind.

Das Team kann Methoden, wie Planning Poker und Big Wall, einsetzen, um die Arbeit in Storypunkten einzuschätzen. Weitere Informationen zu Schätzungsmethoden und eine schnelle Einführung in Storypunkten finden Sie unter Schätzung und Bereinigen und Schätzen des Backlogs.

Nachdem das Team alle Storys geschätzt hat, ist es Zeit für die Priorisierung.

Priorisieren

Alle Product Backlogs werden hinsichtlich des Geschäftswerts und des Risikos priorisiert. Der Product Owner vergleicht jeden Eintrag im Backlog mit den restlichen Einträgen, um die relative Priorität zu ermitteln. Dabei berücksichtigt der Product Owner die Größe der einzelnen Einträge, ihren geschäftlichen Wert und eventuell verbundene Risiken. Die Einträge werden dann nach fallender Priorität sortiert. Einträge mit hoher Priorität werden oben im Product Backlog angezeigt und Einträge mit niedriger Priorität werden weiter unten angezeigt. Teams wählen die Arbeit für den bevorstehenden Sprint aus den Einträgen mit der höchsten Priorität aus, sodass die wichtigsten Aufgaben zuerst fertiggestellt werden.

Nicht alle Einträge im Backlog weisen dieselbe Größe auf. Einige können in einem Sprint abgeschlossen werden, andere sind jedoch so groß, dass sich das Team nicht sicher ist, welcher Aufwand erforderlich ist oder wie lange die Implementierung dauern wird. Das ist kein Problem. Wenn Einträge im Backlog weiter nach oben wandern, wird das Team sie verkleinern und genauer spezifizieren, sodass jeder die Arbeit besser versteht, die in den kommenden Sprints zu erledigen ist.

Wie die Schätzung kann auch die erste Priorisierung des Product Backlogs schwierig erscheinen. Wie stimmen Sie konkurrierende Stakeholder-Anforderungen ab, ohne dabei das Endprodukt, die Risiken und die Kosten aus dem Auge zu verlieren? Glücklicherweise gibt es verschiedene Methoden, die die Aufgabe erleichtern, einschließlich Innovationsspiele und relative Gewichtung. Weitere Informationen zu diesen und anderen Methoden finden Sie unter Priorisierung und Bereinigen und Schätzen des Backlogs.

Unabhängig von der gewählten Methode ist es wichtig, die Arbeit nach Priorität zu ordnen, um sicherzustellen, dass das Team Features erarbeitet, die für das Geschäft, die Stakeholder und die Kunden den höchstmöglichen Nutzen bieten. Ohne Priorisierung erhöhen Sie das Risiko, User Storys mit geringerer statt mit höherer Priorität zu liefern bzw. bei Änderung von Ressourcen und Zeitplänen User Storys unvollständig umzusetzen.

(Weitere Informationen zu den Eigenschaften von Backlog-Einträgen finden Sie unter Erstellen Ihres Backlogs und Arbeiten mit Portfoliobacklogs).

Dynamisches Product Backlog

Bisher ging es vor allem darum, wie Sie aus dem Nichts ein geschätztes und priorisiertes Product Backlog entwickeln. Im Gegensatz zu Anforderungsdokumenten werden Product Backlogs nicht am Anfang des Projekts erstellt, um sie dann im Regal verstauben zu lassen. Product Backlog werden mit den jeweils aktuellen Gegebenheiten des Projekts stetig weiterentwickelt, erweitert und verkleinert. Einige Einträge des Product Backlogs verlieren an Bedeutung und müssen entfernt werden. Dafür kristallisieren sich andere heraus und müssen in kleinere Storys unterteilt werden. Neue User Storys werden hinzugefügt, geschätzt und priorisiert, wenn zusätzliche Anforderungen auftreten.

Das Team und die Stakeholder sind zwar an der Erstellung und Verwaltung des Product Backlogs beteiligt, die Verantwortung liegt aber letztendlich beim Product Owner. Der Product Owner muss sicherstellen, dass das Backlog korrekt, priorisiert und aktuell ist, damit sowohl die Kunden als auch das Team eine genaue Vorstellung vom Arbeitsplan für die Projektfreigabe erhalten. Auch wenn das Projekt in vollem Gange ist, haben Product Owner noch viel zu tun, um das Product Backlog aktuell zu halten::

Hinzufügen und Priorisieren neuer Storys
Beauftragen des Teams, neue Storys zu schätzen und bereits vorhandene Storys neu zu schätzen, wenn neue Informationen vorhanden sind
Prüfen aufkommender User Storys mit dem Team, um Einträge nach Bedarf zu unterteilen
Treffen mit Kunden und Stakeholdern, um Anforderungen zu prüfen und hinzuzufügen

Product Backlog-Einträge können von jedem jederzeit hinzugefügt werden, aber nur der Product Owner darf sie priorisieren. Der Product Owner ist auch der einzige, der einer Story eine Priorität zuweisen kann. Alle anderen Teammitglieder und Stakeholder sollten beim Hinzufügen einer Story keine Priorität angeben, auch wenn sie von dem verwendeten elektronische Tool dazu aufgefordert werden.

Wenn eine Story hinzugefügt wird, nimmt der Product Owner basierend auf seinem Verständnis der Story eine vorläufige Bewertung der Priorität vor. Der Product Owner wird die Story mit dem Ersteller besprechen, um wiederum in der Lage zu sein, Fragen vom Team zu beantworten. Zu einem vorher festgelegten Zeitpunkt in jedem Sprint trifft sich der Product Owner mit dem Team, um neue Storys zu besprechen und gemeinsam zu schätzen, damit sie im Vergleich zu anderen Storys im Backlog besser priorisiert werden können. Dieser Vorgang wird als Grooming des Backlogs bezeichnet.

Grooming

Product Backlog-Grooming muss, wie bereits erwähnt, regelmäßig stattfinden.

Ein Scrum-Team sollte 5 % bis 15 % seiner Zeit in jedem Sprint mit Grooming-Aktivitäten verbringen. Das Team muss über neue Entwicklungen und Änderungen auf dem Laufenden bleiben, um große Storys mit wachsender Priorität unterteilen, neu erstellte Storys schätzen und aufkommende Storys kurzfristig konzipieren und planen zu können. Dazu sollten der Product Owner und das Team bei jedem Sprint-Planungstreffen zusätzliche Zeit im Sprint für das gemeinsame Grooming des Backlogs einplanen. Weitere Informationen zur Sprint-Planung finden Sie unter Sprintplanung und Verwenden von Sprints.

In einem zweiwöchen Sprint halte ich diese Treffen gerne in der zweiten Woche ab. Dadurch erhält der Product Owner genug Zeit, ausführlich mit den Kunden und Stakeholdern zu kommunizieren, ein Verständnis der sich ändernden Geschäftsanforderungen zu erlangen und vorhandene oder neue User Storys bzw. Storys mit wachsender Priorität zu klären. Dies ist auch der logische Zeitpunkt im Sprint, um mit der Vorbereitung der kommenden Sprints zu beginnen. Sie können entscheiden, wann Sie dieses Treffen abhalten. Wichtig ist, dass für Grooming-Aktivitäten ausreichend Zeit im Sprint vorhanden ist.

Während eines typischen Grooming-Treffens stellt der Product Owner alle Neuigkeiten, Änderungen und den Plan für die nächsten Sprints vor. Zusätzlich zum Schätzen neuer Storys und Unterteilen von bald abzuschließenden Storys nimmt sich das Team während dieses Treffens Zeit, die aktuelle Architektur des Systems zu prüfen und kommende Features zu planen bzw. zu entwerfen. Im Laufe dieses Prozesses werden Story-Schätzungen oft geändert und neue Storys kommen auf, während größere Storys in kleinere Storys aufgeteilt werden.

Dieser Prozess scheint simpel, kann sich jedoch als ein wenig konfliktbeladen erweisen. Um einen reibungslosen Ablauf zu garantieren muss der Product Owner bereit sein, Fragen zu beantworten. Konflikte können beispielsweise auftreten, wenn der Product Owner plant, eine Story im nächsten Sprint umzusetzen, aber dem Team nicht die nötige Klarheit bieten kann, um eine gute Schätzung abgeben zu können. Wenn eine solche Situation während eines Sprint-Planungstreffens eintritt, sollt der Scrum Master den Product Owner dabei beraten, welche Informationen von den Kunden und Stakeholdern für das Team beschafft werden müssen.

Am Ende jedes Grooming-Treffens sollte der Product Owner die Änderungen an die Stakeholder und Kunden weiterleiten, damit alle über neue und bevorstehende Entwicklungen und den aktuellen Freigabeplan informiert sind.

Ein gutes Product Backlog hilft sicherzustellen, dass die von Ihnen entwickelte Software die wichtigsten Features aufweist, die in den Besprechungen mit den Kunden und Stakeholdern ermittelt und in den User Storys definiert wurden. Um ein gutes Product Backlog zu erstellen und zu pflegen, müssen Sie sowohl mit der Stakeholder/Kunden-Gruppe als auch mit dem Team regelmäßig in jedem Sprint aktiv in Kommunikation stehen.

Ein gutes Backlog garantiert kein gutes System, aber das Fehlen eines guten Backlogs wird höchstwahrscheinlich dazu führen, dass Sie ein System erhalten, das nicht den Anforderungen der Kunden entspricht. Mit anderen Worten: Wenn das Backlog nicht auf dem aktuellsten Stand gehalten wird, wird das Projekt fast immer ein Fehlschlag.

Product Owner ist eine Vollzeitaufgabe und das Backlog liegt in seiner bzw. ihrer Verantwortung. Nehmen Sie diese Rolle ernst. Halten Sie das Product Backlog in einem guten Zustand und Ihre Kunden werden es Ihnen danken.