„Done“, oder: Wann ist etwas fertig?

Eines der wichtigsten Konzepte in Scrum sind „Sprints“. Sprints sind Iterationen fester Länge, an deren Ende ein potentiell auslieferungsfähiges Produktinkrement steht.

Es wird zwar noch nicht den kompletten Funktionsumfang aufweisen. Diejenigen Anforderungen, die bereits umgesetzt wurden, sind jedoch schon auf einem Stand, an dem man sie auch an Endkunden verkaufen könnte. Dies bedeutet, daß alle in einem Inkrement enthaltenen Anforderungen als „fertig“ (engl. „done“) betrachtet werden können.

Doch was genau bedeutet denn nun „fertig“?

Die Schritte, die durchlaufen werden müssen, um eine Anforderung als „done“ zu betrachten, werden vor Projektbeginn genau definiert. Ein Beispiel wäre z.B. „Damit eine Anforderung fertig ist, muss sie vollständig implementiert, zu 100% durch Unit-Tests abgedeckt und ausreichend dokumentiert sein. Sie darf keine bekannten Fehler mehr enthalten und muß vom Kunden abgenommen worden sein“.

In der Realität ist es sogar so, daß jedes Projekt seine eigene Definition von „done“ haben wird, je nach Projektumfeld und -rahmenbedingungen. In einem anderen Projekt könnte diese Definition aber schon wieder ganz anders aussehen.

Entscheidend dabei ist jedoch gar nicht unbedingt das Aussehen der Definition. Wichtiger ist, dafür zu sorgen, daß alle Projektbeteiligten von derselben Definition sprechen. Andernfalls würde dies mindestens einen erhöhten Aufwand bei der Statusverfolgung, meistens jedoch auch verminderte Qualität bedeuten („Wir haben noch nie etwas getestet“). In jedem Fall jedoch bremst dies das Team unnötig aus.

Natürlich kann es auch vorkommen, daß ein Team es nicht schafft, innerhalb eines Sprints ein auslieferungsfähigs Inkrement zu bauen. Dies ist beispielsweise dann der Fall, wenn bis zum Ende des Sprints nicht alle vorgesehenen Tests gemacht werden können (etwa weil noch kein automatisiertes Testframework existiert).

In diesem Fall, so der Vorschlag von Ken Schwaber („Scrum Guide“, Mai 2009, S.13-14), kann man für jedes Inkrement zwei Kategorien einführen: „Done“ und „Undone“.

  • Alles, was komplett fertiggestellt ist (gemäß der Definition), wird in „Done“ einsortiert.
  • Arbeiten, die aus irgendeinem Grund erst zu einem späteren Zeitpunkt abgeschlossen werden können, werden nach „Undone“ sortiert.

Auf diese Weise hat man immer im Blick, welche Arbeiten vor der Auslieferung noch erledigt werden müssen (z.B. in einer Art „Release Sprint“ o.ä.). Einen kleinen Nachteil hat diese Methode jedoch: Das Wachstum der Kategorie „Undone“ ist nicht einfach vorherzusagen. Sie wird zwar im Normalfall nur linear wachsen. Im schlechtesten Fall ist jedoch auch ein exponentielles Wachstum denkbar.

Dies macht es jedoch schwer, die Zahl der restlichen Sprints bis zur Auslieferung vorherzusagen. Die Vorhersage wird dabei umso genauer sein, je linearer das Wachstum der Spalte „Undone“ ist, und ungenauer, je mehr exponentielles Wachstum auftritt.

BFI

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Suche

Kategorien

Aktuelle Umfrage

Wie würden Sie die EURO-Krise meistern?

Ergebnisse anzeigen

Wird geladen ... Wird geladen ...
Carls überraschende  KI-Blindheit

Carls überraschende KI-Blindheit

Carl und Gerlinde (80) „Ist Carl wirklich so blind…? Oder will er die diversen Tretmienen auf dem Weg zu seiner…
Bitte keine Könige, Präsidenten und Wahlen ...

Bitte keine Könige, Präsidenten und Wahlen ...

IETF - völlig unterschätzt und einzigartig organisiert!
SUCHE
Drücken Sie "Enter" zum Starten der Suche