Erstellen und Verwalten des Produktrückstands

Artikel
02/26/2013

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 Produktrückstands und beschreibt, was einen guten Rückstand ausmacht. Zudem stellt er einige bewährte Vorgehensweisen zum Erstellen und Verwalten des Rückstands vor.

Betrifft

Application Lifecycle Management; Team Foundation Server

In diesem Artikel:

Einführung
Produktrückstand
- User Stories
- Schätzung
- Priorisierung
Produktrückstand nicht statisch
- Bereinigung
Schlussfolgerung

Ein Produktrückstand ist eine nach Prioritäten geordnete Liste aller Funktionen und Funktionalitäten, die zum Abschließen eines Projekts erforderlich sind.Ein guter Produktrückstand stellt für jedes agile Team eine Kernkomponente dar und weist folgende Merkmale auf:

Er wird mit Prioritäten versehen, damit sichergestellt ist, dass das Team die wichtigsten Funktionen zuerst erstellt.
Er wird vom Team geschätzt, damit der Produktbesitzer nicht im Unklaren bleibt und Fragen wie „Wann werden diese Stories fertig gestellt sein?“ beantworten kann.
Er enthält die gesamte Arbeit, die zum Abschließen des Projekts nötig ist.
Er ist kein statisches Dokument, sondern verändert und entwickelt sich, um die jeweils aktuellen Situationen des Projekts widerzuspiegeln.

Ein guter Produktrückstand ist kein automatischer Garant für gute Software.Wenn jedoch kein guter Produktrückstand vorhanden ist, führt dies häufig zu unvollständiger Software, die nicht die Anforderungen von Kunden und Beteiligten erfüllt.

Die Verwaltung des Produktrückstands ist eine Vollzeitbeschäftigung.Einfache Verfahren helfen dabei, aus einem überwältigenden und zeitaufwendigen Prozess einen interaktiven und iterativen Prozess zu machen, in den Teammitglieder, Kunden und Beteiligte effektiv einbezogen werden.Daher ist es ausgesprochen wichtig, zuverlässige Verfahren kennenzulernen, die Ihnen beim Erstellen, Priorisieren und Verwalten des Produktrückstands helfen.

Produktrückstand

Der Produktrückstand ist eine nach Prioritäten angeordnete, nicht statische Hauptliste aller Funktionen und Funktionalitäten, die zum Abschließen des Projekts erforderlich sind.Produktrückstände enthalten häufig User Stories für Anforderungen (z..B.. Anforderungen), Fehler, Forschungsaufgaben (Spitzen) und die Technik von Verbesserungen.Diese Elemente werden in abstrakten Einheiten geschätzt, die als Storypunkte bezeichnet werden.

Produktrückstände enthalten alle Arbeiten, die für das Projekt notwendig sind, und entwickeln sich im Verlauf der Zeit.Folglich sind im Produktrückstand nicht nur die neuen Funktionen für ein Produkt enthalten, sondern auch Fehlerkorrekturen und Recherchen – eben alles, was die Zeit des Teams in Anspruch nimmt.Alle vom Team ausgeführten Tätigkeiten müssen aus dem Produktrückstand stammen: Er bildet das Eingangsportal zum Projekt.Sind im Produktrückstand sämtliche Arbeiten genannt, erhalten Produktbesitzer, Team und Management ein besseres Bild der noch verbleibenden Schritte. So werden auch Überraschungen in letzter Minute verhindert.

Zu Beginn des Projekts werden Sie sicherlich keine Liste mit fehlerfreien und gut definierten Produktrückstands-Elementen, die Sie nur noch schätzen und mit Prioritäten versehen müssen, in der Hand halten.Wahrscheinlicher ist, dass Sie stattdessen einen Stapel mit Story-Anmerkungskarten und vielleicht eine oder zwei Funktionsbeschreibungen haben.Als Produktbesitzer ist es Ihre Aufgabe, diese unsortierten Vorlagen zu sortieren, sodass das Team mit der Schätzung des Rückstands beginnen kann.

User Stories

Der erste Schritt besteht darin, alle Ideen und Anmerkungen in User Stories zu konvertieren. Diese sollen die vom Endbenutzer gewünschte Funktionalität (also was die Software leisten soll) darstellen, aber keine Implementierungsdetails (wie die Software erstellt wird, die diese Anforderungen erfüllt) enthalten.Der Titel jeder User Stories sollte das Format „Als <Benutzer> möchte ich <Funktionalität>, damit <Begründung>“ aufweisen.

Beispiel für eine Story Card

Wie der Produktrückstand selbst entwickelt sich auch jede User Story im Zeitverlauf.Im Verlauf des Projekts priorisiert und schätzt das Team diese User Stories, fügt ausführliche Informationen hinzu, gliedert sie in kleinere Stories oder löscht sie vollständig.Die in Sprints eingebundenen User Stories werden implementiert und an die Kunden ausgeliefert.

Weitere Informationen über User Stories finden Sie unter Erstellen des Produktrückstands oder Hinzufügen zum Produktrückstand und Rückstands-Element eines Storyboards mithilfe von PowerPoint.

Nachdem alle Ideen und Anmerkungen in User Stories konvertiert sind, ist es an der Zeit, diese zu schätzen und zu priorisieren.

Schätzung

Definitionsgemäß ist die Schätzung ungenau.Mit Übung und der Beteiligung des gesamten Teams können Sie aber nach einer Weile relativ genaue Schätzungen erstellen. Der erste Schritt besteht darin, das Team zusammenzurufen, damit Schätzungen zu den Produktrückstands-Elementen bereitgestellt werden.Beim Einschätzen durch das Team erfolgt eine relative Größeneinschätzung mit einer abstrakten Maßeinheit, die als Storypunkt bezeichnet wird.

Schätzungen sind aus zwei Gründen wichtig:

Sie helfen, die Frage „Wann werden wir damit fertig sein?“ zu beantworten.
Sie helfen dem Produktbesitzer, die Priorität der einzelnen Elemente zu ermitteln.

Mit den Schätzungen erhalten sowohl der Produktbesitzer als auch das Team eine Vorstellung von den Kosten einer bestimmten Story. Das wiederum hilft dem Produktbesitzer dabei, die Stories in Relation zueinander mit Prioritäten zu versehen.Je höher ein Element geschätzt wird, desto teurer wird dessen Implementierung in Bezug auf Zeit und Ressourcen sein.Möglicherweise bekommt so ein Element, das auf der Wunschliste des Produktbesitzers zunächst sehr weit oben stand, bei sehr hohen Kosten eine geringere Priorität zugewiesen.

Das Team kann die Arbeit für die Storypunkte unter Zuhilfenahme von Verfahren wie Planning Poker, Wandschätzverfahren und anderen schätzen.Weitere Informationen über Schätzverfahren und eine Kurzeinführung in Storypunkte finden Sie unter Schätzung und Bereinigen und Schätzen des Rückstands.

Nachdem das Team alle Stories geschätzt hat, erfolgt die Priorisierung.

Priorisierung

Alle Produktrückstände werden im Hinblick auf Geschäftswert und Risiko priorisiert.Der Produktbesitzer vergleicht jedes Element im Rückstand mit den anderen, um die relative Priorität zu bestimmen.Dazu berücksichtigt der Produktbesitzer bei jedem Element dessen Größe sowie den Geschäftswert und alle zugehörigen Risiken.Dann werden die Elemente in absteigender Reihenfolge nach ihrer Priorität sortiert.Elemente mit hoher Priorität werden oben oder relativ weit oben im Produktrückstand angezeigt, Elemente mit niedriger Priorität befinden sich hingegen weiter unten oder unten.Im nächsten Sprint wählen die Teams ihre Arbeit aus den Elementen mit höchster Priorität aus, damit die wichtigsten Elemente zuerst abgeschlossen werden.

Die Elemente im Rückstand weisen nicht die gleiche Größe auf.Einige lassen sich in einem Sprint abschließen, andere wiederum sind so groß, dass das Team nicht genau sagen kann, was für die Implementierung nötig ist oder wie lange sie dauern wird.Das ist kein Problem.Wenn die Elemente an die Spitze des Rückstands aufrücken, werden sie vom Team in kleinere und kompaktere Einheiten untergliedert. So kann jeder die Arbeit, die er in den kommenden Sprints zu erledigen hat, besser nachvollziehen.

Ebenso wie bei der Schätzung kann auch die Priorisierung des ursprünglichen Produktrückstands eine gewaltige Aufgabe sein.Wie wird ein Gleichgewicht von konkurrierenden Anforderungen der Beteiligten bei gleichzeitiger Berücksichtigung von Endprodukt, Risiken und Kosten erzielt?Es sind mehrere Techniken, die die Aufgabe erleichtern, einschließlich Innovations-Spiele und relative Gewichtung.Weitere Informationen darüber und über andere Methoden finden Sie unter Sprintplanung und Bereinigen und Schätzen des Rückstands.

Unabhängig von der Priorisierungsmethode, für die Sie sich entscheiden, müssen Sie die Arbeit in eine Reihenfolge bringen. So wird sichergestellt, dass das Team die Funktionen erstellt, die den höchsten Wert für das Geschäft, die Beteiligten und die Kunden darstellen.Wenn Sie die Arbeit nicht priorisieren, erhöht sich das Risiko, dass User Stories mit geringerer Priorität (anstelle von hoher) sowie unvollständige User Stories (bei veränderten Zeitplänen und Ressourcen) abgeliefert werden.

(Weitere Informationen über die Natur der Rückstandselemente finden Sie unter Erstellen des Produktrückstands oder Hinzufügen zum Produktrückstand und Agile-Planung und -Iterationen).

Produktrückstand nicht statisch

Was ich bisher beschrieben habe, konzentrierte sich darauf, bei null zu beginnen und einen geschätzten und priorisierten Produktrückstand zu schaffen.Anders als ein Anforderungsdokument werden Produktrückstände nicht bei Projektbeginn erstellt, um dann in ein Regal gelegt zu werden.Stattdessen entwickelt sich der Produktrückstand, wird je nach Situation des Projekts erweitert und geschrumpft.Einige Produktrückstands-Elemente werden unwichtig und müssen entfernt werden.Andere hingegen drängen in den Vordergrund und müssen in kleinere Stories aufgegliedert werden.Mit zusätzlich aufkommenden Anforderungen werden auch neue User Stories hinzugefügt, geschätzt und priorisiert.

Der Produktrückstand wird vom Team und den Beteiligten erstellt und verwaltet, die letztliche Verantwortung für ihn liegt aber beim Produktbesitzer.Der Produktbesitzer muss sicherstellen, dass der Rückstand fehlerfrei, priorisiert und aktuell ist, damit sowohl die Kunden als auch das Team ein klares Bild des Arbeitsplans für die Projektversion bekommen.Auch wenn das Projekt in vollem Gange ist, haben Produktbesitzer noch viel Arbeit damit, den Produktrückstand aktuell zu halten:

Neue Stories hinzufügen und priorisieren
Team sowohl zum Schätzen neuer Stories als auch (mit zunehmenden Kenntnissen) zum erneuten Schätzen alter Stories auffordern
Anstehende User Stories mit dem Team überprüfen, um die Elemente nach Bedarf zu untergliedern
Mit Kunden und Beteiligten besprechen, um Anforderungen zu überprüfen und hinzuzufügen

Jeder kann dem Produktrückstand jederzeit Elemente hinzufügen, das Priorisieren hingegen obliegt allein dem Produktbesitzer.Der Produktbesitzer ist auch die einzige Person, die einer Story eine Priorität zuweisen kann.Alle anderen Teammitglieder und Beteiligten sollten beim Hinzufügen einer neuen Story die Priorität nicht angeben. Das gilt auch, wenn das verwendete elektronische Tool sie zur Eingabe dieser Informationen auffordert.

Nachdem eine Story hinzugefügt ist, nimmt der Produktbesitzer eine vorläufige Bewertung ihrer Priorität vor, die auf seinen Kenntnissen dieser Story beruht.Er bespricht die Story mit ihrem Ersteller, um seine Kenntnisse darüber zu vertiefen, damit er dann seinerseits in der Lage ist, die vom Team gestellten Fragen zu beantworten.In jedem Sprint gibt es einen vorher festgelegten Zeitpunkt, an dem der Produktbesitzer neue Stories mit dem Team erörtert und gemeinsam schätzt, um die neuen Stories in Relation zu den anderen Stories im Rückstand präziser priorisieren zu können.Dieser Prozess wird als Rückstandsbereinigung bezeichnet.

Bereinigung

Wie bereits gesagt, muss der Produktrückstand regelmäßig bereinigt werden.

In Scrum sollte das Team in jedem Sprint 5 bis 15 Prozent mit Bereinigungsaktivitäten verbringen.Das Team muss wissen, was als Nächstes kommt und welche Änderungen anliegen, um große Stories zu untergliedern, die in der Prioritätenliste nach oben steigen, und um erstellte Stories zu schätzen und neue Entwürfe sowie Planungen für anstehende Stories anzufertigen.Um dies sicherzustellen, sollten der Produktbesitzer und das Team in jeder Sprintplanungsbesprechung einige Zeit einplanen, um den Rückstand gemeinsam zu bereinigen.Weitere Informationen über die Sprintplanung finden Sie unter Sprintplanung und Planen einer Iteration.

Wenn der Sprint zwei Wochen dauert, halte ich diese Besprechung am liebsten in der zweiten Woche ab.So hat der Produktbesitzer ausreichend Zeit, um aussagekräftige Gespräche mit den Kunden und Beteiligten zu führen, sich ein Bild von den Änderungen im Geschäft zu verschaffen und die User Stories sowie neue oder in der Priorität steigende Stories abzuklären.Es ist auch ein logischer Zeitpunkt im Sprint, die kommenden Sprints zu bedenken.Sie können entscheiden, wann die Besprechung stattfindet.Wichtig ist, dass im Sprint genügend Zeit eingeräumt wird, um die Bereinigungsaktivitäten auszuführen.

Während einer typischen Bereinigungsbesprechung stellt der Produktbesitzer Neuerungen und Änderungen sowie seinen Plan für die nächsten Sprints vor.Das Team nimmt sich Zeit, um neue Stories zu schätzen und solche, die zeitnah abgeschlossen werden müssen, zu untergliedern. Zusätzlich wird in dieser Besprechung Zeit eingeräumt, um die aktuelle Systemarchitektur zu überprüfen und Planungen oder Entwürfe für anstehende Funktionen zu schaffen.Während dieses Prozesses werden die Schätzungen der Stories häufig geändert, und neue große Stories werden in kleinere Stories untergliedert.

Dieser Prozess scheint einfach, kann aber auch zur Herausforderung werden.Damit alles reibungslos verläuft, muss der Produktbesitzer darauf vorbereitet sein, Fragen zu beantworten.Ein Konflikt kann beispielsweise auftreten, wenn der Produktbesitzer die Ausführung einer Story im nächsten Sprint plant, aber nicht die klärenden Informationen liefern kann, die das Team für eine gute Schätzung benötigt.Falls dies während der Sprintplanungsbesprechungen geschieht, sollte der Scrum-Master dem Produktbesitzer erklären, welche Informationen von Kunden und Beteiligten er dem Team übermitteln muss.

Am Ende jeder Bereinigungsbesprechung sollte der Produktbesitzer Kunden und Beteiligte über die Änderungen und den aktualisierten Versionsplan informieren, damit alle wissen, welche Neuerungen und Veränderungen erfolgt sind.

Ein guter Produktrückstand hilft bei der Sicherstellung, dass die von Ihnen erstellte Software über die wichtigsten Funktionen verfügt, die in den Gesprächen mit Kunden und Beteiligten ermittelt und in den User Stories definiert worden sind.Um einen guten Produktrückstand zu erstellen und zu erhalten, müssen Sie einen aktiven Kontakt zur Gruppe der Beteiligten/Kunden sowie zum Team halten, der regelmäßig stattfindet – in jedem Sprint.

Ein erstellter guter Rückstand ist kein Garant für ein gutes System. Ist jedoch kein guter Rückstand vorhanden, ist praktisch sicher, dass Ihr System nicht das leisten wird, wonach der Kunde verlangt hat.Mit anderen Worten: Wenn der Rückstand nicht auf dem neuesten Stand ist, führt das fast immer zu einem Projektfehlschlag.

Produktbesitzer zu sein, ist eine Vollzeitbeschäftigung – und der Rückstand untersteht seiner Verantwortung.Nehmen Sie diese Rolle ernst.Halten Sie den Produktrückstand in einem guten Zustand, und Ihre Kunden werden es Ihnen danken.