Aktivitäten am Ende eines Sprints

  • Artikel

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Am Ende eines Sprints können Teams verschiedene Aufgaben zum Aufrechterhalten der Backloghygiene ausführen. Im Allgemeinen sollten unvollständige Arbeiten niemals einem zurückliegenden Sprint zugewiesen sein. Teams müssen entscheiden, wie sie Arbeiten handhaben, die in einem Sprint nicht abgeschlossen wurden, und geeignete Maßnahmen ergreifen.

Hinweis

Es gibt kein automatisches Verfahren, um unvollständige Arbeitselemente, die einem Sprint zugewiesen sind, in einen anderen Sprint zu verschieben. Es ist auch keine automatische Methode zum Festlegen von Verbleibende Arbeit auf null verfügbar.

Am Ende jedes Sprints sollten Teams die folgenden Fragen beantworten und entsprechende Maßnahmen ergreifen:

  • Wie verfahren wir mit User Storys und den zugehörigen Aufgaben, die am Ende des Sprints nur teilweise abgeschlossen sind?
  • Was ist die richtige Vorgehensweise zum Verwalten teilweise erledigter Arbeiten am Ende des Sprints, damit Sprintmetriken und die Geschwindigkeit korrekt berücksichtigt werden?
  • Was sollten wir überprüfen, und in welcher Reihenfolge führen wir diese Überprüfungen durch?

Im Allgemeinen sollten Aktivitäten am Ende eines Sprints vor oder nach einer Sprintreviewbesprechung und vor einer Sprintretrospektive durchgeführt werden. Wichtig ist vor allem die Verwaltung von Ansichten und Metriken, die das Team bei Sprintreviews, Retrospektiven und der Sprintplanung heranziehen kann.

Ziele für Aktivitäten am Ende eines Sprints

Jeder Sprint stellt einen zeitgesteuerten Entwicklungszeitraum dar, dem Arbeit zugewiesen wird. Die folgende Checkliste enthält die Ziele, die Sie beim Durchführen der Aktivitäten am Ende eines Sprints vor Augen haben sollten.

  • Aufrechterhalten der Backloghygiene – einem Sprint, dessen Enddatum in der Vergangenheit liegt, dürfen keine unvollständigen Arbeiten zugewiesen sein
  • Verwalten von Arbeitselementzuständen und Sprintzuweisungen, um die Überwachung des Fortschritts und der Geschwindigkeit des Teams zu unterstützen
  • Unterstützen der Aktivitäten des Teams zur kontinuierlichen Verbesserung
  • Unterstützen der Fokussierung des Teams auf die Lieferung von Software und die Erfüllung von Sprintzielen
  • Minimieren von Arbeitsüberwachungsaktivitäten, die keinen Nutzen bieten

Tipp

Die Geschwindigkeit des Teams ist kein Maß für seine Produktivität und sollte nur als Metrik für die Planung zukünftiger Sprints verwendet werden. Eine Arbeit ist am Ende eines Sprints entweder abgeschlossen oder nicht abgeschlossen. Wurde sie erledigt, zählt sie für den Sprint. Arbeiten, die nicht erledigt wurden, werden nicht für den aktuellen Sprint berücksichtigt, sondern einem zukünftigen Sprint erneut zugewiesen. Die Geschwindigkeit gleicht sich in der Regel von selbst aus, egal welche Entscheidungen Sie treffen. Wenn Sie jedoch nur erledigte Arbeiten berücksichtigen, erhalten Sie einen realistischeren Wert und eine deutlich bessere Quelle an historischen Daten, auf die Sie sich bei zukünftigen Planungen stützen können.

Festlegen der Teampräferenzen

Im Folgenden werden die wichtigsten Aktivitäten am Ende eines Sprints vorgestellt, deren Durchführung Teams in Erwägung ziehen sollten. In der Regel sollten diese Aktivitäten am letzten Tag des Sprints oder nach der Sprintreviewbesprechung durchgeführt werden.

  • Überprüfen Sie das Sprintbacklog auf unvollständige User Storys, Backlog Items und Aufgaben. Dazu können Sie das Sprintbacklog überprüfen oder das Sprint-Taskboard.

  • Weisen Sie User Storys, Backlog Items und Aufgaben, die nicht begonnen wurden, dem Product Backlog oder dem nächsten Sprint neu zu. Im Bereich „Planung“ können Sie Arbeitselemente dem Teambacklog oder einem zukünftigen Sprint neu zuweisen. Neu zugewiesene Arbeitselemente können erneut geschätzt und priorisiert werden.

  • Entscheiden Sie, wie unvollständige User Storys, Backlog Items oder Aufgaben behandelt werden sollen. Denken Sie daran, dass das Ziel darin besteht, funktionierende Software zu liefern. Hier gibt es zwei Möglichkeiten:

    • Teilen Sie die Story in zwei Storys auf, um die im aktuellen Sprint abgeschlossene Arbeit und die noch zu erledigende Arbeit darzustellen. Weitere Informationen finden Sie unter Kopieren oder Klonen von Stories, Ausgaben und anderen Arbeitsaufgaben.
    • Weisen Sie die Story dem nächsten Sprint zu, in dem die Arbeit abgeschlossen werden kann. Alle nicht abgeschlossenen Storys im aktuellen Sprint werden mit null auf die Geschwindigkeit des Sprints angerechnet.

  • Entscheiden Sie, wie verbleibende Arbeit für abgeschlossene Aufgaben behandelt werden soll. Wenn Aufgaben abgeschlossen sind, ist ein Wert ungleich null für Verbleibende Arbeit nicht sinnvoll. Teams sollten entscheiden, wie sie in diesen Fällen vorgehen und den Wert von Verbleibende Arbeit für abgeschlossene Aufgaben ggf. auf null festlegen.

Überprüfen des Sprintbacklogs auf unvollständige Arbeiten

Um unvollständige Arbeiten zu ermitteln, überprüfen Sie das Sprintbacklog auf Arbeiten, die sich noch im Zustand „Committet“, „Aktiv“ und „In Bearbeitung“ befinden. Screenshot: Sprintbacklog am Ende des Sprints.

Erneutes Zuweisen unvollständiger User Storys und Aufgaben zu zukünftigen Sprints

Wählen Sie im Sprintbacklog Ansichtsoptionen und dann Planung aus. Ziehen Sie die Arbeitselemente, die unvollständig sind, per Drag & Drop in den nächsten Sprint oder wieder in das Teambacklog.

Wie im folgenden Screenshot gezeigt, entspricht das Backlog von Fabrikam Team dem Standarditerationspfad, der für das Team festgelegt ist. Beachten Sie, dass der Iterationspfad erst beim Start des nächsten Sprints geändert wird, wenn der Standardwert auf das Makro @CurrentIteration festgelegt ist.

Screenshot: Sprintbacklog mit aktiviertem Bereich „Planung“.

Archivieren zurückliegende Sprints

Im Laufe der Zeit kann die Anzahl der Sprints, die für ein Projekt definiert oder einem Team zugewiesen sind, zunehmen. Um die Anzahl der Einträge im Dropdownmenü für die Iterationspfade zu minimieren, können Projektadministrator*innen zurückliegende Sprints in einen Archivbereich verschieben. Wenn die Sprintzuweisung beibehalten, aber unter einen anderen Sprintknoten verschoben wird, werden alle Arbeitselementdaten beibehalten. Alle Sprintdiagramme und Widgets funktionieren weiterhin.

Im folgenden Screenshot wurden Sprints aus den Jahren 2012 und 2013 unter den Knoten Vorherige Sprints verschoben.

Screenshot: Unter dem Knoten „Vorherige Sprints“ archivierte Iterationspfade.

Tipp

Alle in Arbeitselementen gespeicherten Daten werden von Azure DevOps verwaltet, bis die Arbeitselemente endgültig gelöscht werden.

Tipps für die Sprinthygiene

Das Sprintbacklog verweist als aktiven Sprint basierend auf dem Start- und Enddatum automatisch auf den aktuellen Sprint. Wenn das aktuelle Datum innerhalb des Sprintzeitraums liegt, ist der entsprechende Sprint der aktuelle Sprint. Es ist keine weitere Aktion erforderlich, um den nächsten Sprint zum aktiven aktuellen Sprint zu machen.

Projekt- oder Teamadministrator*innen sollten beim Verwalten von Sprints die folgenden Richtlinien befolgen.

  • Die Start- und Enddatumsangaben, die für die Sprints Ihres Projekts definiert sind, dürfen sich nicht überlappen.
  • Alle Sprints, die für ein Team von Interesse sind, sollten für die Konfiguration dieses Teams ausgewählt werden.
  • Mehrere zukünftige Sprints sollten für Ihr Projekt definiert und für Ihre Teams ausgewählt werden.

Weitere Informationen finden Sie unter Definieren Sie Iterationspfade (Sprints) und konfigurieren Sie Teamiterationen.