Scrum

Scrum ist ein Framework zum Ausführen von Projekten, das auf agilen Prinzipien und Werten basiert. Es definiert einen Satz von Aktivitäten, die das Team bei der ergebnisorientierten Entwicklung und schnellen Bereitstellung von Ergebnissen für den Kunden unterstützen. Diese Aktivitäten bieten Ihren Kunden die Möglichkeit, die fortschreitende Arbeit des Teams zu prüfen, anzuleiten und zu beeinflussen. Dieser Ansatz versucht nicht, alles zu Beginn eines Projekts zu definieren. Stattdessen arbeitet das Team in kurzen Iterationen (auch als Sprints bezeichnet) und optimiert den Plan, während Fortschritte erzielt werden. Informationen zu den agilen Prinzipien und den Werten, auf denen Scrum basiert, finden Sie unter Prinzipien und Werte der agilen Softwareentwicklung, von Jeff Sutherland.

MSF for Agile Software Development v5.0 basiert auf Scrum. Daher kann das Team Scrum mithilfe von Tools adaptieren, die bereits in die Kernentwicklungsaktivitäten integriert sind.

In diesem Thema Vorbereiten auf das Projekt Planen des Projekts Planen eines Sprints Ausführen eines Sprints Nachverfolgen des Projekts

Vorbereiten auf das Projekt

Bevor Sie mit dem Projekt beginnen, führen Sie die folgenden Aufgaben aus:

• Etablieren des Geschäftsziels

• Zusammenstellen eines Teams

• Einrichten der Infrastruktur des Teams

Um das Geschäftsziel festzulegen, definieren Sie die Geschäftsanforderung, und nennen Sie eine Begründung, die die Vision definieren und die Finanzierung erarbeiten. Geoffreys Moore's Buch, "Crossing the Chasm", bietet eine fundierte Hilfestellung zum Definieren Ihrer Vision. Weitere Informationen finden Sie auf der folgenden Microsoft-Webseite: Crossing the Chasm.

Nachdem Sie das Geschäftsziel festgelegt haben, müssen Sie das Team zusammenstellen und den Scrummaster und Produktbesitzer benennen. Weitere Informationen finden Sie unter Rollen.

Schließlich muss das Team die Infrastruktur einrichten. Installieren Sie zum Beispiel Visual Studio Team Foundation Server und Visual Studio Application Lifecycle Management (ALM), erstellen und passen Sie ggf. das Teamprojekt an, und richten Sie die Entwicklungsverfahren ein. Weitere Informationen finden Sie unter Erste Schritte mit der Verwaltung des Lebenszyklus von Anwendungen für Visual Studio, Anpassen des Teamprojekts und Entwicklungsverfahren.

Planen des Projekts

In einem Scrum-Projekt investiert das Team den Großteil der Zeit in eine Reihe von Sprints, in denen das Produkt entwickelt wird. Das Team muss jedoch zuerst einen übergeordneten Plan für das Projekt erstellen. Dieser Plan dient als Roadmap für alle weiteren Detailentscheidungen, die das Team im Laufe des Projekts trifft. Gleichzeitig mit der Implementierung des Plans durch das Team werden sich auch Änderungen ergeben. Wenn das Team die Projektplanung abgeschlossen hat, wurden vom Team ein Produktrückstand und, falls erforderlich, ein Veröffentlichungsplan erstellt.

Erstellen des Produktrückstands

Der Produktrückstand ist eine Liste von Benutzertextabschnitten, in denen die Anforderungen und Wünsche der Benutzer beschrieben werden. Die Benutzertextabschnitte werden nach ihrem Geschäftswert und ihrem Risiko priorisiert, und das Team bewertet Benutzertextabschnitte in abstrakten Einheiten, die als Textabschnittspunkte bezeichnet werden.

	Erstellen von User Storys: > In seinem Buch "User Stories Applied" definiert Mike Cohn Benutzertextabschnitte folgendermaßen: "Ein Benutzertextabschnitt beschreibt eine Funktionalität, die von einem Benutzer oder vom Käufer eines Systems oder einer Software geschätzt bzw. gewünscht wird." Benutzertextabschnitte werden aus der Sicht der Endbenutzer geschrieben. Beispiel: "Als wiederkehrender Kunde möchte ich eine Mahlzeit bestellen können, die ich bereits beim letzten Mal bestellt habe." Weitere Informationen finden Sie unter Erstellen eines vorzüglichen Produktrückstands.
	Priorisieren der Benutzertextabschnitte: Der Produktbesitzer priorisiert die Benutzertextabschnitte im Produktrückstand in enger Zusammenarbeit mit den Kunden, um zu verstehen, welche Funktionen den Kunden wichtig sind. Außerdem erfolgt zusammen mit dem Team eine Einschätzung der Risiken und Abhängigkeiten. Der Produktbesitzer definiert Prioritäten, indem er jedem Benutzertextabschnitt einen Rang zuweist und so die Reihenfolge festlegt, in der das Team die Abschnitte implementieren sollte. Der Produktbesitzer kann verschiedene Techniken verwenden, um den Wert eines Benutzertextabschnitts zu analysieren und zu vergleichen. Wenn das Team bereits über eine etablierte und funktionierende Priorisierungsmethode verfügt, sollte diese Methode weiterhin verwendet werden. Einige Priorisierungstechniken sind eng mit der agilen Community verknüpft, z. B. das Kano-Modell für Kundenzufriedenheit und die relative Gewichtung nach Karl Wiegers. (Weitere Informationen zur relativen Gewichtung finden Sie auf der folgenden Seite im Internet: First Things First: Prioritizing Requirements.) Andere Priorisierungstechniken, z. B. Kostenpriorisierung, Nettobarwert, Amortisationszeitraum und interner Ertragssatz, sind außerhalb der agilen Community hinreichend etabliert. Diese Techniken sind ebenfalls geeignet, den Produktrückstand eines Scrumprojekts zu priorisieren. Weitere Informationen finden Sie unter "Part II: Estimating Size" in dem Buch, das unter der folgenden Webressource verfügbar ist: Agile Estimation and Planning.
	Bewerten der Benutzertextabschnitte: Das Team bewertet gemeinsam jeden Benutzertextabschnitt und erstellt Textabschnittspunkte. In seinem Buch "Agile Estimation and Planning" definiert Mike Cohn Textabschnittspunkte wie folgt: "Textabschnittspunkte sind eine Maßeinheit zur Beschreibung der Gesamtgröße eines Benutzertextabschnitts, einer Funktion oder einer anderen Arbeitsaufgabe." Textabschnittspunkte sind relative Werte, die sich nicht direkt in eine bestimmte Anzahl an Stunden umsetzen lassen. Stattdessen helfen Textabschnittspunkte einem Team, die allgemeine Größe des Benutzertextabschnitts zu bestimmen. Diese relativen Schätzungen sind weniger präzise, sodass ihre Festlegung weniger aufwändig ist und sie sich im Laufe des Projekts häufiger als zuverlässige Schätzung erweisen. Durch das Schätzen der Textabschnittspunkte ermittelt das Team sofort eine allgemeine Größe der Benutzertextabschnitte und erstellt erst später eine detaillierte Einschätzung des genauen Arbeitsaufwands in Stunden, unmittelbar bevor die Teammitglieder mit dem implementieren der Benutzertextabschnitte beginnen.

Bestimmen der Geschwindigkeit des Teams

Bevor das Team seinen Veröffentlichungsplan erstellt und die einzelnen Sprints plant, muss es seine Geschwindigkeit bestimmen. Die Geschwindigkeit des Teams ist die Anzahl von Textabschnittspunkten, die es in einem Sprint abschließen kann.

Wenn das Team bereits seine Geschwindigkeit durch das Sammeln von Daten gemessen hat, die zeigen, wie viele User Storys das Team in einem bestimmten Zeitraum abschließen kann, verwenden Sie diese Daten zur Bestimmung. Sie stellen den besten Einblick in die Geschwindigkeit des Teams dar. Wenn Sie noch nicht über solche Daten verfügen und Sie das Projekt mit Visual Studio ALM und MSF for Agile Software Development v5.0 durchführen, werden die nötigen Daten im Verlauf des Projekts gesammelt. Weitere Informationen finden Sie unter Bericht "Status für alle Iterationen".

Wenn Verlaufsdaten nicht verfügbar sind, kann das Team eine ungefähre Schätzung der Textabschnittspunkte vornehmen, die es im ersten Sprint abschließen kann. Betrachten Sie die User Storys mit der höchsten Priorität, und geben Sie eine schnelle Einschätzung darüber ab, wie viele der User Storys in einem Sprint abgeschlossen werden können. Fügen Sie die User Storys für jede dieser User Storys hinzu, um eine anfängliche Schätzung zu erhalten. Nach dem ersten Sprint können Sie die Geschwindigkeit des Teams anhand der Verlaufsdaten bestimmen. Bei den ersten Sprints sollten Sie deutliche Abweichungen erwarten, da das Team zunächst lernen muss, verlässliche Schätzungen vorzunehmen. Nach mehreren Sprints sollte die gemessene Geschwindigkeit des Teams zuverlässiger werden. Wenn die gemessene Geschwindigkeit des Teams stabil ist, muss der Veröffentlichungsplan neu beurteilt werden.

Die Schätzung der Geschwindigkeit des Teams stellt einen Ausgangspunkt dar, mit dem Sie bestimmen können, wie viele Benutzertextabschnitte in einem Sprint implementiert werden können. Diese Schätzung ist aber nicht die Grundlage für die endgültigen Teamvorgaben. Die Teamvorgaben werden auf Grundlage ausführlicherer Schätzungen der Aufgaben erstellt, die zum Abschließen der Benutzertextabschnitte erforderlich sind. Weitere Informationen finden Sie unter Arbeitsmappe "Produktplanung".

Festlegen des Veröffentlichungsplans

Mit jedem Sprint schließt das Team einen Teil des endgültigen Produkts ab. Auch wenn die Benutzertextabschnitte, die das Team implementiert, am Ende des Sprints für die Auslieferung bereit sind, wurden möglicherweise noch nicht genügend Geschäftswerte realisiert, um eine tatsächliche Veröffentlichung des Produkts zu rechtfertigen. Planen Sie die Versionen, indem Sie sie Iterationen zuweisen:

• Identifizieren Sie Gruppen von User Story, die genügend Geschäftswert für eine Auslieferung an den Kunden bieten.

• Bestimmen Sie, in welchen Sprints das Team mit der Fertigstellung dieser Gruppen von User Storys rechnet.

Im Zuge des Projektfortschritts werden die User Storys dem Produktrückstand hinzugefügt, und User Storys werden möglicherweise entfernt. Zudem ändert sich die Priorität einiger User Storys, und einige User Storys werden möglicherweise früher oder später als zunächst erwartet implementiert. Der Produktbesitzer behält den Veröffentlichungsplan zusammen mit dem Produktrückstand im Verlaufe des Projekts.

Weitere Informationen finden Sie unter Arbeitsmappe "Produktplanung".

Vorbereiten auf den ersten Sprint

Ein Sprint ist eine zeitlich eingegrenzte Entwicklungsiteration, die normalerweise 1 bis 4 Wochen umfasst und zum Abschluss eines bestimmten Teils des endgültigen Produkts führt. Bevor das Team den ersten Sprint beginnt, bereitet der Produktbesitzer den Produktrückstand vor. Die Benutzertextabschnitte, deren Priorität hoch genug ist, um sie im ersten Sprint zu berücksichtigen, müssen soweit definiert sein, dass sie vom Team implementiert werden können. Der Produktbesitzer muss den Produktrückstand vorbereiten, indem er die folgenden Aufgaben ausführt:

• Aufteilen der User Storys in kleinere User Storys

• Bereitstellen von Details zu den User Storys, die das Team benötigt, um sie in Aufgaben zu unterteilen

Der Produktbesitzer erkennt einen zu großen Benutzertextabschnitt daran, dass ein wesentlicher Teil der Gesamtgeschwindigkeit des Teams durch den Abschnitt beansprucht wird. Ein Benutzertextabschnitt mit 15 Textabschnittspunkten ist z. B. zu groß für die Besprechung der Sprintplanung, wenn die Geschwindigkeit des Teams bei 30 Textabschnittspunkten liegt. Das Team benötigt die Hälfte des Sprints allein für den Abschluss dieses Benutzertextabschnitts.

Das Team wird auch Detailfragen zu den Benutzertextabschnitten stellen, um in der Lage zu sein, sie in Aufgaben zu unterteilen und den Aufwand für die Aufgaben einzuschätzen. Wenn das Team z. B. die User Story "Als Kunde möchte ich nach einer bestimmten Sorte von Gerichten suchen können" untersucht, stellt es möglicherweise folgende Fragen:

• "Sollte das eine freie Textsuche sein, oder könnte auch eine Auswahlliste der verfügbaren Typen verwendet werden?"

• "Wenn mehr als ein Anbieter eine Mahlzeit anbietet, die der Suche entspricht, wie sollen die Ergebnisse sortiert werden?"

Weitere Informationen finden Sie unter Vorbereitung auf den nächsten Sprint.

Planen eines Sprints

Wenn das Team den Produktrückstand entwickelt und einen Veröffentlichungsplan festgelegt hat, kann es mit dem Arbeiten in Sprints beginnen. Das Team beginnt den Sprint mit einer Sprintplanungsbesprechung, in der das Team sich verpflichtet, einen Satz von Benutzertextabschnitten aus dem Produktrückstand abzuschließen. Dieser Satz von Benutzertextabschnitten, zusammen mit den zugehörigen Aufgaben, bildet den Sprintrückstand. Weitere Informationen finden Sie unter Vergleichen von Produkt- und Sprint-Rückstand.

Nachdem der Sprint begonnen hat, werden die Benutzertextabschnitte im Sprintrückstand nicht mehr geändert. Daher muss der Plan detailliert genug sein, sodass das Team diese Verpflichtung auch zuversichtlich geben kann.

Weitere Informationen finden Sie unter Sprintplanungsbesprechung.

Auswählen von Benutzertextabschnitten

Das Team wählt die Benutzertextabschnitte aus, die für eine Implementierung während des Sprints in Frage kommen. Das Team identifiziert die Benutzertextabschnitte mit der höchsten Priorität, deren Textabschnittspunkte die geschätzte Geschwindigkeit nicht überschreiten. Die vier Benutzertextabschnitte mit der höchsten Priorität haben z. B. 8, 3, 7, 6 und 2 Textabschnittspunkte. Wenn das Team eine Kapazität von 25 Textabschnittspunkten pro Sprint hat, kann es die ersten vier Textabschnittspunkte in den Sprintrückstand aufnehmen.

Weitere Informationen finden Sie unter Arbeitsmappe "Iterationsrückstand".

Identifizieren von Aufgaben

Das Team wertet jeden Benutzertextabschnitt aus, um die Schritte zu bestimmen, die zum Implementieren des Abschnitts erforderlich sind. Das Team gliedert die Benutzertextabschnitte in Aufgaben, um die Benutzertextabschnitte besser zu verstehen und eine zuverlässige Zusicherung geben zu können, dass die Abschnitte im Sprint abgeschlossen werden.

Teams, die sehr erfahren mit Scrum sind, können diese Zusicherung möglicherweise auch geben, ohne die Benutzertextabschnitte in Aufgaben aufzugliedern.

Schätzen von Aufgaben

Nachdem die Aufgaben identifiziert wurden, schätzt das Team, wie lange (in Stunden) jede Aufgabe dauert. Teams bewerten Aufgaben häufig mit der Planning-Poker-Technik. Diese Technik verhindert, dass Teams versuchen, genauer zu schätzen als notwendig ist.

Zusichern von Benutzertextabschnitten

Das Team verwendet die Arbeitsmappe Iterationsrückstand, um sicherzustellen, dass das Team über genügend Arbeitszeit für alle Aufgaben verfügt. Wenn der Sprint mehr Arbeit beinhaltet, als dem Team für den Sprint zur Verfügung steht, müssen die Benutzertextabschnitte mit der niedrigsten Priorität entfernt werden, bis die Arbeit innerhalb der Sprintkapazität liegt. Kleinere Abschnitte mit niedrigerer Priorität können anstelle größerer Storys einbezogen werden, die nicht in den Sprint passen.

Das Team sichert zu, die ausgewählten Benutzertextabschnitte abschließen zu können. Es macht diese Zusicherung unter der Voraussetzung, dass der Produktbesitzer nicht versucht, zusätzliche Arbeiten einzuführen oder die Prioritäten der Benutzertextabschnitte zu ändern, die im Sprint implementiert werden.

Ausführen eines Sprints

Während eines Sprints führt das Team die Aufgaben aus, die erforderlich sind, um die Benutzertextabschnitte im Sprintrückstand zu implementieren. Das Team kann seinen Status verfolgen und stellt sicher, dass es die Akzeptanzkriterien der Kunden und die Kriterien des Teams für fertige Software erfüllt, bevor ein Sprint beendet wird.

Vollständige Benutzertextabschnitte

Nachdem das Team den Sprint geplant hat, verfügt es über eine Liste mit Benutzertextabschnitten, die während des Sprints verlässlich abgeschlossen werden sollen. Diese Benutzertextabschnitte wurden in Aufgaben aufgegliedert. Jedes Teammitglied registriert sich für eine Aufgabe, sobald der Sprint beginnt. Nach dem Abschließen der Aufgabe aktualisiert das Teammitglied den Status und registriert sich für eine andere Aufgabe. Auf diese Weise arbeitet das Team die Liste der Aufgaben ab und vervollständigt die Benutzertextabschnitte im Sprintrückstand. Ein Teammitglied kann beim Einchecken von Code angeben, welche Aufgaben abgeschlossen wurden. Weitere Informationen finden Sie unter Zuordnen von Arbeitsaufgaben zu Changesets.

Weitere Informationen zum Zuweisen von Aufgaben und Aktualisieren des Status finden Sie unter Aufgabe (Agile).

Scrum verlässt sich mehr auf Personen, die sich untereinander austauschen, als auf formale Prozesse, um sicherzustellen, dass Abhängigkeiten verstanden, Kenntnisse weitergegeben und Änderungen in Plänen effizient durchgeführt werden. Berufen Sie jeden Tag eine kurze Scrumbesprechung ein, in der jedes Teammitglied über die Arbeit des vorherigen Tages Auskunft gibt, die Arbeit des bevorstehenden Tages beschreibt und eventuelle Probleme oder Hindernisse anspricht, die die Hilfe anderer Teammitglieder erfordern oder deren Arbeit beeinflussen könnten. Weitere Informationen finden Sie unter Tägliche Scrumbesprechung.

In seinem Buch "Extreme Programming Explained" redet Kent Beck darüber, dass es billiger ist, einen Fehler lieber früher als später zu beheben. Unter Berücksichtigung dieser Tatsache muss das Team verstehen, welche Punkte für den Kunden wichtig sind. Vielleicht schätzt der Kunde Qualität mehr als zahlreiche Funktionen. Der Produktbesitzer muss solche Informationen sammeln, da die Kunden den Fluss der Arbeit zum Team steuern.

Die Software, die ein Scrumteam erstellt, sollte fehlerfrei sein. Dennoch wird das Team während des Projekts auf Fehler treffen. Behandeln Sie Fehler mit dem Verständnis, dass es billiger und schneller ist, sie unmittelbar nach ihrem Auftreten zu korrigieren. Wenn das Team Fehler findet, sind diese sofort zu beheben. Wenn das Team den Fehler nicht am selben Tag beheben kann, erstellen Sie in Visual Studio ALM eine Fehlerarbeitsaufgabe, und führen Sie diese vor Ende des Sprints aus.

Weitere Informationen finden Sie unter Fehler (Agile).

Verfolgen des Sprintstatus

Das Team kann den Status des Sprints verfolgen, um sicherzustellen, dass die Arbeit wie erwartet abgeschlossen wird und dass die Akzeptanzkriterien erfüllt werden. Scrumteams verwenden meistens einen Burndownbericht, um den Status in einem Sprint zu verfolgen. MSF for Agile Software Development v5.0 stellt einen Satz von Berichten bereit, mit denen Teams den Status eines Sprints verfolgen können.

Bericht "Burndown und Verbrauchsrate" (Agile)

Bericht "Buildqualitätsindikatoren"

Bericht "Testplanstatus"

Bericht "Storystatus" (Agile)

Teams stellen oft fest, dass sie weniger oder mehr Zeit für eine Aufgabe benötigen, als während der Sprintplanungsbesprechung eingeplant wurde. Diese Art von Abweichungen ist typisch. Sie können diese Informationen erfassen, indem Sie die tatsächliche Zeit angeben, die das Team mit der Aufgabe verbracht hat.

Während der Sprint fortschreitet, identifiziert das Team eventuell Aufgaben, die es nicht erwartet hatte, die aber notwendig sind, um einen Benutzertextabschnitt zu vervollständigen. Erstellen Sie in diesem Fall eine Aufgabe, schätzen Sie sie, und ermitteln Sie anschließend, ob das Team sie in dem Zeitraum abschließen kann, der noch für den Sprint vorgesehen ist. Wenn das Team die Aufgabe abschließen kann, fahren Sie mit dem Sprint fort. Wenn das Team die Aufgabe nicht im Sprint abschließen kann, beraumen Sie ein Treffen mit dem Produktbesitzer an, um das weitere Vorgehen zu erläutern. Der Produktbesitzer und das Team können das Problem beheben, indem sie die folgenden Arten von Änderungen vornehmen:

• Reduzieren der Akzeptanzkriterien für die User Story, sodass die Aufgabe nicht mehr relevant ist

• Entfernen der User Story aus dem Sprintrückstand

• Abbrechen des Sprints

Beenden des Sprints

Zum Ende des Sprints stellen Sie sicher, dass das Team alle User Storys oder Anforderungen vollständig abschließt. Stellen Sie z. B. sicher, dass die Akzeptanztests erfolgreich verlaufen und dass jede User Story die Kriterien erfüllt, die das Team festgelegt hat. Weitere Informationen zu der Bedeutung finden Sie auf der folgenden Webseite:Mitch Lacey & Associates, Inc.

Bericht "Fehlerstatus"

Bericht "Fehlertrends"

Am letzten Tag des Sprints stellt das Team den abgeschlossenen Benutzertextabschnitt dem Produktbesitzer und möglicherweise auch den Kunden vor. Der Produktbesitzer und die Kunden bestimmen, ob sie jeden der Benutzertextabschnitte annehmen. Weitere Informationen finden Sie unter Sprint-Prüfbesprechung.

Nach der Prüfung durch die Kunden hält das Team eine Retrospektive ab. Weitere Informationen finden Sie unter Nachbereitungsbesprechung.

Nachverfolgen des Projekts

Während das Team in Sprints einzelne Teile des Projekts erarbeitet, entwickeln die Kunden ein besseres Verständnis der noch verbleibenden Anforderungen, und es müssen Änderungen der Geschäftsumgebung in Betracht gezogen werden. Der Produktbesitzer arbeitet zusammen mit den Kunden, um diese Änderungen zu verstehen. Der Produktbesitzer pflegt den Produktrückstand und den Veröffentlichungsplan, um die Änderungen wiederzugeben und sicherzustellen, dass das Team zu Beginn jedes Sprints über alle nötigen Informationen verfügt. Das Team verfolgt den Status des Produkts insgesamt, um sicherzustellen, dass das Projekt gute Fortschritte macht und eine fehlerfreie Fertigstellung zu erwarten ist.

Vorbereitung für den nächsten Sprint

Die Aktualität des Produktrückstands steht in direkter Beziehung zur Gesamtqualität und zur Vollständigkeit des Projekts. Der Rückstand muss regelmäßig aktualisiert, geändert und überdacht werden, um sicherzustellen, dass er jedes Mal bereit ist, wenn das Team einen neuen Sprint beginnt.

Der Produktbesitzer bereitet den Produktrückstand auf den nächsten Sprint vor, indem er die folgenden Aufgaben ausführt:

• Aktualisieren der User Storys und ihrer Prioritäten, wenn sich Kundenanforderungen ändern

• Unterteilen von User Storys, die wahrscheinlich im nächsten Sprint implementiert werden

Sobald das Team einen Sprint beendet, steigt die Priorität anderer Benutzertextabschnitte im Produktrückstand. Der Produktbesitzer muss die Storys, die sich am Anfang der Liste befinden, analysieren und aufschlüsseln, damit das Team sie im kommenden Sprint implementieren kann. (Weitere Informationen finden Sie in diesem Thema weiter oben unter Vorbereitung auf den ersten Sprint). Mike Cohn spricht häufig über diesen Prozess als Eisberg des Produktrückstands. Wenn das Team an einem Satz von Funktionen arbeitet, schmilzt der Eisberg. Neue Aufgaben werden sichtbar, und die Größe des Eisbergs nimmt ab. Bei diesem Prozess kommen Stück für Stück weitere Details zum Vorschein, nicht zu viele und immer zum richtigen Zeitpunkt.

Während das Team mit einem Sprint beschäftigt ist, kann der Produktbesitzer nicht erwarten, dass das Team sich mit dem gleichen Engagement an der Pflege des Produktrückstands beteiligt wie bei der Vorbereitung auf den ersten Sprint. Um den Produktbesitzer bei der Vorbereitung des Produktrückstands bei möglichst geringer Unterbrechung des Sprints zu unterstützen, erörtern das Team und der Produktbesitzer die noch offenen Fragen zum Produktrückstand im Verlauf des Sprints.

Verfolgen des Veröffentlichungsstatus

Während das Projekt von Sprint zu Sprint fortschreitet, verfolgt das Team den Gesamtstatus bis zur nächsten Veröffentlichung einer Version. Das Team verfolgt den Status auch, um die Teamgeschwindigkeit bewerten und verbessern zu können. Bei dieser Verfolgung des Status sollte das Team versuchen, die folgenden Arten von Fragen zu beantworten:

• Arbeiten wir an den Benutzertextabschnitten mit der höchsten Priorität? Der Produktrückstand wird im Verlauf des Projekts durch neue Benutzertextabschnitte ergänzt. Wenn die Gesamtzahl der Abschnitte im Rückstand jedoch nicht sinkt, obwohl Sie bei jedem Sprint Abschnitte abschließen, sollte das Team die Ursache hierfür untersuchen. Die Storys, die abgeschlossen wurden, wurden eventuell nicht optimal ausgewählt. Das Team sollte eine Vision und ein Ziel für jede Version haben und sicherstellen, dass die Benutzertextabschnitte sich unmittelbar an den Anforderungen des Kunden orientieren.

• Häufen wir technische Schulden an? Einige Teams behandeln einen Benutzertextabschnitt als beendet, obwohl noch Arbeiten, z. B. Fehlerbehebung, abgeschlossen werden müssen. Diese Teams häufen technische Schulden an, die sie später begleichen müssen, und durch die Verzögerung wachsen die Kosten in aller Regel.

Visual Studio ALM stellt mehrere Berichte bereit, mit denen das Team seinen Status im Verlauf vieler Sprints verfolgen kann.

Bericht "Status für alle Iterationen"

Bericht "Übersicht über Storys" (Agile)

Bericht "Storystatus" (Agile)

Sie können benutzerdefinierte Berichte und Arbeitsaufgabenabfragen erstellen, um den Status noch genauer zu verfolgen. Weitere Informationen finden Sie unter Erstellen, Anpassen und Verwalten von Berichten für die Anwendungslebenszyklus-Verwaltung von Visual Studio und Suchen nach Fehlern, Aufgaben und anderen Arbeitsaufgaben.

Beenden der Version

Wenn das Team keine technischen Schulden akkumuliert, kann es das Produkt veröffentlichen, sobald alles Sprints in einer Version abgeschlossen wurden, ohne irgendeine zusätzliche Arbeit. Das Team und der Produktbesitzer führen rückblickende Besprechungen und Prüfungen zusammen mit dem Kunden durch, um die Version als ganzes zu untersuchen.

Technische Schulden sind jedoch immer ein wesentliches Problem, das Teams nicht leicht eliminieren können. Wenn das Team, wie viele andere Teams, immer noch technische Schulden anhäuft, muss es Zeit dafür aufwenden, die ausstehende Arbeit und die User Storys abzuschließen, bevor das Produkt veröffentlicht werden kann. Überlegen Sie in der Retrospektive für die Version, was das Team in bevorstehenden Sprints unternehmen muss, um eine weitere Akkumulation von technischen Schulden zu vermeiden.

Siehe auch

Konzepte

Entwicklungsverfahren

Auswählen einer Prozessvorlage

Planen und Nachverfolgen von Projekten

Weitere Ressourcen

MSF for Agile Software Development, Version 5.0