Menü

Scrum-Artefakte: Product Backlog, Sprint Backlog und Product Increments

  • Haupt
  • Andere
  • Scrum-Artefakte: Product Backlog, Sprint Backlog und Product Increments

scrum artifacts product backlog

Versuchen Sie Unser Instrument, Um Probleme Zu Beseitigen

Einführung in Scrum-Artefakte:

In den vorherigen Artikeln dieser Reihe wurden wir vorgestellt agil und die verschiedenen agilen Methoden . Wir haben auch gelernt, wie sich die verschiedenen Methoden auf ihre Weise unterscheiden.

In unserem letzten Tutorial haben wir uns mit den Details von Scrum befasst, in denen wir das besprochen haben Scrum-Rollen wie Product Owner, Scrum Master und das Scrum-Team und sah, was ihre individuellen Verantwortlichkeiten waren.

In diesem Tutorial fahren wir mit Scrum fort und gehen weiter auf die Details zu den verschiedenen Scrum-Artefakten ein.

Scrum-Artefakte

Was du lernen wirst:

Verschiedene Scrum-Artefakte

3 Arten von Scrum-Artefakten umfassen:

  • Produktrückstand
  • Sprint-Rückstand und
  • Produktinkremente

Jetzt werden wir sehen, was diese Begriffe bedeuten und wie diese Artefakte erstellt werden.

Scrum Artifacts-Typen

Produktrückstand

Einfach ausgedrückt ist ein Product Backlog eine Liste aller Dinge, die für das Produkt erforderlich sind. Es ist das endgültige Dokument, auf das sich das Scrum-Team für alles bezieht, was mit dem Produkt zu tun hat. Es handelt sich um eine geordnete Liste von Artikeln, die dem Product Owner (PO) gehören.

Die Bestellung ist für die Erstellung, Pflege und Priorisierung dieser Liste verantwortlich. Die POs verwenden dieses Produkt-Backlog, um den Scrum-Teams die wichtigsten Anforderungen zu erläutern, die während des Sprints zu erfüllen sind.

Die Elemente in dieser Liste können in einer technischen Sprache verfasst sein oder nicht. Es kann sogar eine Laiensprache sein, sollte jedoch alle Produktanforderungen und die damit verbundenen Änderungen enthalten. Ein Product Backlog bedeutet auch nicht, dass das Scrum-Team nur dieses Artefakt hat, dem es folgen kann.

Sie können ihre eigenen detaillierten Artefakte erstellen, diese widersprechen jedoch nicht dem Produktstau oder ersetzen ihn. Sie werden eher mit den Anforderungen an den Produktbestand übereinstimmen.

Im Folgenden finden Sie ein Beispiel dafür, wie ein typischer Produktstau aussehen kann:

GeschichteSchätzenPriorität
Ich möchte mich anmelden41
Ich möchte mich abmeldenzweizwei
Ich möchte das Passwort ändern13
Ich möchte die Adresse aktualisieren34
Ich möchte eine neue private Telefonnummer hinzufügen15

Dies bringt uns zu der Frage: Wie erstelle ich einen guten Produktstau?

Ein Product Backlog sollte idealerweise den folgenden Regeln folgen:

(i) Es sollte priorisiert werden - Die Artikel im Product Backlog sollten nach Priorität bestellt werden. Diese Priorität kann von der PO und dem Scrum-Team gemeinsam festgelegt werden. Die Priorisierungsfaktoren können von dem Story Point, dem Aufwand für die Erstellung, der Komplexität, der Kundenpriorität usw. profitieren.

Es hilft dem Team zu verstehen, was zuerst geliefert werden muss.

(ii) Es sollte geschätzt werden - Die Geschichten sollten immer gemäß der vereinbarten Definition geschätzt werden, was auch immer das sein mag. Dies kann auch zur Priorisierung verwendet werden.

(iii) Es sollte ein hohes Niveau sein - Die Storys im Product Backlog sind auf hohem Niveau und sollten nicht ins Detail gehen. Die Erstellung detaillierter User Stories gemäß den Anforderungen liegt beim Scrum-Team und nicht bei der Bestellung.

(iv) Es sollte dynamisch sein - Das Product Backlog ist kein endgültiges statisches Dokument. Es sollte erneut überprüft werden, wenn die Bestellung Eingaben vom Scrum-Team erhält und die Kundenanforderungen immer klarer werden. Daher werden die Dokumentanforderungen nicht gleich zu Beginn eingefroren, da im Verlauf des Projekts Ergänzungen / Löschungen / Änderungen erwartet werden.

Der letzte Punkt ist der relevanteste. Der Zweck eines Product Backlogs besteht darin, eine aktive Anforderungsquelle zu sein. Es darf nicht am Anfang erstellt und dann an einem Speicherort aufbewahrt werden.

Stattdessen soll es immer wieder geteilt werden, wenn die Änderungen immer wieder auftauchen. Im Laufe der Fortschritte können sich neue Anforderungen ergeben, die auch die Priorität der Backlog-Elemente ändern können. Es wird Situationen geben, in denen eine neue Anforderung von einem anderen Element im Backlog abhängt, sodass die Elementpriorität möglicherweise neu gemischt werden muss.

Oder es gibt eine kritische User Story, die möglicherweise zuerst implementiert werden muss, weil der Kunde dies vor den anderen sehen möchte, obwohl die Priorität gemäß den von der Bestellung und dem Scrum-Team festgelegten Faktoren möglicherweise nicht hoch ist.

Somit ist das Product Backlog eine geordnete Liste von Geschäftsanforderungen, die der Bestellung gehören und im Verlauf des Projekts immer wieder pünktlich besucht werden.

Sprint Backlog

Sie werden sich vielleicht daran erinnern, dass die Scrum-Teams in kurzen Iterationen von 2 bis 4 Wochen arbeiten, die als Sprint bezeichnet werden. Während dieser Sprints identifiziert das Scrum-Team die Elemente aus dem von der Bestellung erstellten Produkt-Backlog, die sie als Teil der nächsten Iteration liefern möchten. Die Elemente, an denen das Scrum-Team arbeitet, werden Teil des Sprint-Backlogs.

So entscheiden sie, welche Funktionen in der nächsten Iteration des Produkts vorhanden sein sollen. Das Scrum-Team entscheidet, was in den Sprint-Rückstand aufgenommen wird, da sie daran arbeiten werden.

Daher sollten sie den Aufwand für die Umsetzung dieser Geschichten abschätzen und entscheiden, wie viel sie liefern können.

Das Team wählt nicht nur die Elemente aus dem Produkt-Backlog aus, an denen gearbeitet werden soll, sondern schätzt auch, wie lange es dauern wird, bis diese Funktionalität entwickelt ist. Sie ergänzen auch die allgemeinen User Stories, indem sie detaillierte Aufgaben erstellen, die zum Erreichen des Sprintziels erforderlich sind.

Online-Backup-Software für Dienstleister

Das Scrum-Team kann das Sprint-Backlog auch bei Bedarf während des Sprints aktualisieren, aber nur das Scrum-Team kann Änderungen am Sprint-Backlog vornehmen.

Ein typisches Sprint-Backlog sieht wie folgt aus.

Sprint Backlog

Das Team kann dies idealerweise einmal am Tag aktualisieren und der Scrum Master kann diese Informationen verwenden, um ein Sprint-Burndown-Diagramm zu erstellen. Anhand dieser Burndown-Tabelle kann das Team erkennen, wie viel Arbeit noch für den Sprint übrig ist, und das Team kann seine Arbeit entsprechend planen. Bei Bedarf können sie sogar Aufgaben hinzufügen oder entfernen.

Einige bewährte Methoden beim Erstellen eines Sprint-Backlogs können sein:

# 1) Gruppenentscheidungen treffen - Es sollte nicht der Scrum Master oder ein anderes Scrum Teammitglied sein, das über den Rückstand entscheidet. Vielmehr sollte das gesamte Team gemeinsam entscheiden, welche Elemente in den Sprint-Rückstand aufgenommen werden sollen und wie sie geplant werden sollen.

Jedes Mitglied dieses funktionsübergreifenden Teams bringt seine eigenen Fähigkeiten mit und es ist wichtig, dass wir ihre Erfahrung nutzen, um den bestmöglichen Rückstand zu schaffen.

# 2) Keine Aufgaben zuweisen - Weisen Sie den Teammitgliedern niemals Aufgaben zu, da dies in der agilen Literatur mehrfach wiederholt wurde. Ein Scrum-Team soll autark sein und wissen, wie man seine Arbeit selbst organisiert.

Anstatt also Arbeit zuzuweisen, sollten wir das Team die Arbeit für sich selbst auswählen lassen und untereinander entscheiden, wie sie vorgehen möchten.

# 3) Definition von erledigt - Dies sollte nicht nur von den Stakeholdern vereinbart, sondern dem Team an allen Punkten klar sichtbar gemacht werden, wenn es eine Entscheidung über die Sprintziele treffen muss. Dies dient als Erinnerung daran, was genau getan werden muss, bevor ein funktionierendes versandfähiges Produkt geliefert werden kann.

# 4) Aktualisiere den Rückstand weiter - Es ist unbedingt erforderlich, dass das Team mit der Weiterentwicklung des Sprints ein besseres Verständnis gewinnt und daher den Sprint-Rückstand entsprechend aktualisiert, um auch dieses bessere Verständnis widerzuspiegeln. Es sollte zu keinem Zeitpunkt ein statisches Dokument werden.

# 5) Fügen Sie eine beliebige Aufgabe hinzu - Die Aufgabe muss sich nicht nur auf die Codierung beziehen, sondern es kann auch wichtig sein, ein versandfähiges Produkt zu liefern. Erwähnen Sie daher solche Aufgaben auch im Backlog.

Produktinkremente

Dies bringt uns zum letzten Scrum-Artefakt, bei dem es sich um die Produktinkremente handelt. Wie in der Scrum-Anleitung definiert, ist ein Inkrement die Summe aller Product Backlog-Elemente abgeschlossen während a Sprint und den Wert der Inkremente aller vorherigen Sprints. Wie wir inzwischen gut wissen, ist Scrum ein iterativer Prozess.

Das Ergebnis jeder Iteration ist dieses Produktinkrement, und jedes dieser Produktinkremente hilft dem Team, der Bereitstellung des Endprodukts einen Schritt näher zu kommen.

Dies bedeutet, dass alles, was das Ergebnis des Sprints war, ein Inkrement ist. Damit das Ergebnis als Inkrement betrachtet werden kann, sollte es zunächst die vordefinierte Definition von 'erledigt' erfüllen, d. H. Das Endergebnis sollte ein verwendbares Produkt sein, das 'versendet' werden kann.

Es kann überprüft, verwendet und getestet werden, um sicherzustellen, dass es tatsächlich gemäß der Definition „erledigt“ ist. Wenn der Product Owner dies wünscht, kann es auch für die Inbetriebnahme freigegeben werden.

Das Wichtigste, um dieses Produktinkrement zu liefern, ist ein gemeinsames Verständnis der von allen verstandenen „Definition von erledigt“.

Das Scrum-Team sollte niemals Zweifel haben, ob das, was es tut, akzeptiert wird oder nicht. Im Zweifelsfall sollte die Definition von erledigt vollständig genug sein, um sie bei der weiteren Vorgehensweise zu unterstützen. Nur basierend auf dieser Definition entscheidet das Scrum-Team, wie viele Product Backlog-Elemente für den Sprint ausgewählt werden sollen.

Dies ist das Minimum, wie es vom Sprint erwartet wird.

Fazit

In diesem Tutorial haben wir die drei Scrum-Artefakte verstanden, denen sie gehören, sowie einige der Best Practices, mit denen wir Artefakte von besserer Qualität erstellen können. In unseren nächsten Tutorials dieser Reihe werden wir die Scrum-Ereignisse diskutieren und sehen, wie diese Ereignisse ausgeführt werden.

In unserem kommenden Tutorial zu „Scrum Veranstaltungen , Wir werden jedes Scrum-Event im Detail besprechen!

PREV Tutorial | NÄCHSTES Tutorial

Literatur-Empfehlungen

^