Defintion of Ready und Definition of Done

Die Defition of Done (DoD), oder auch Level of Done (LoD) genannt, bestimmt wann eine User Story als done bezeichnet werden darf. Die Definition of Ready (DoR) bestimmt, ob ein Product Backlog Item ausreichend beschrieben ist, um es in ein Sprint Backlog aufzunehmen. Beide Definitionen haben zum Ziel die Story-Qualität zu erhöhen um damit ein besseres Produkt-Ergebnis zu erzielen.

Interne und externe Anforderungen


Die Definition of Done beinhaltet dabei sowohl Punkte aus der Organisation heraus als auch teamspezifische Anforderungen.

Aus der Organisation kann zum Beispiel die Anforderung entstehen, dass Code Reviews zwingend erforderlich sind. Als Anforderung aus dem Team könnte zum Beispiel der Push in den Master Git-Branch als Anforderung definiert werden.

Diese Anforderungen gelten global für alle Product Backlog Items des Teams.

DoD: ein Team-Angelegenheit

Im Verlauf des Sprints werden die einzelnen Punkte des DoD abgehakt, bis alle berücksichtigt worden sind. Das Scrum Development Team ist zuständig für die Einhaltung des DoD.

Hat das Team die Story verstanden?

Anders als das DoD beinhaltet die Definition of Ready Kriterien an Product Backlog Items. Erst wenn diese Kriterien erfüllt sind, kann eine User Story in den aktuellen Sprint des Teams übernommen werden.

Die DoR stellt dabei allerdings keine Einlasskontrolle für das Sprint Planning 1 dar, sondern auch im Rahmen des SP1 kann die DoR erfüllt werden.

Product Owner füllt DoR aus

Der Product Owner ist zuständig für die Erfüllung des DoR und sorgt somit für die Qualität der Product Backlog Items. Inhalte eines DoR können zum Beispiel sein:

  • Die User Story ist formal beschrieben
  • Acceptance Criteria wurden definiert
  • Der Umfang der User Story ist klein genug, so dass sie in einem Sprint umgesetzt werden kann
  • Die User Story wurde geschätzt

Checkliste zur Einführung von SCRUM

Folgen Sie dieser Checkliste, um SCRUM erfolgreich in Ihrem Unternehmen anzuwenden.

Wenn das so einfach wäre…

Eine erfolgreiche Einführung von SCRUM oder agilem Projektmanagement hängt von sehr vielen Faktoren ab, die von Unternehmen zu Unternehmen ganz unterschiedlich sind. Die Firmenkultur spielt genauso eine Rolle wie die Anzahl der Mitarbeiter und den Wille und die Notwendigkeit zur Änderung der Projektmanagement-Prozesse.

Bei der Einführung von SCRUM können verschiedene Vorgehensweisen angewandt werden. Eine Möglichkeit ist es mit Hilfe des DMAIC-Zyklus den aktuellen IST-Stand zu analysieren und Optimierungen herauszuarbeiten. Diese werden eingeführt und die Einführung anschließend begleitet.

Einsatz des DMAIC-Zyklus zur SCRUM-Einführung

Zur Einführung von SCRUM oder generell agilen Methoden (oder Optimierung der bereits bestehenden agilen Struktur) wird eine Prozessanalyse mit Hilfe des DMAIC-Zyklus durchgeführt. Dabei wird das Change-Projekt in der Define-Phase zunächst definiert und es werden Kennzahlen für ein Messverhalten von Optimierungen in der Measure-Phase aufgestellt.

Anschließend erfolgen die Analyse des IST-Prozesses, sowie eine Zusammenstellung von Maßnahmen zur Verbesserung/Einführung in der Improve-Phase.

Den Abschluss bildet die Phase Control, in der zum einen Werkzeuge für ein mit agilen Werten vertretbares Controlling aufgestellt werden und zum anderen die Begleitung des Prozesses nach den Einführung projektiert wird.

Die Define-Phase

Diese Phase beinhaltet vor allem die Auftragsklärung mit Hilfe eines Inception Sheets / Project Inception. In diesem werden die Projektbeteiligten definiert, die Risiken und Stakeholder aufgestellt und ein erster Projektplan erstellt.

Weitere mögliche Inhalte in dieser Phase sind:

  • Projektstrukturplan
  • RACI-Chart
  • Kommunikationsplan
  • CTC- / CTB-Analyse

Die Measure-Phase liefert Kennzahlen

In dieser Phase werden Kennzahlen erhoben. Z.B. könnte hier herausgestellt werden, wie viele Releases es pro Jahr gibt oder wie viele Bugs nach einem Release in den darauf folgenden 14 Tagen gemeldet werden. Ein weiterer Punkt kann eine Auswertung der Termintreue sein.

Die Analyse-Phase beginnt

Typische Elemente wie eine SWOT-Analyse oder eine Ursache-Wirkung-Analyse bilden den Kern der Analyse-Phase. In dieser Phase wird der aktuelle Prozess durchleuchtet und werden Maßnahmen zur Optimierung herausgearbeitet.

Die Umsetzung beginnt: die Improve-Phase

SCRUM oder agiles Projektmanagement wird im Rahmen der Improve-Phase eingeführt. Es finden Workshops statt, die Teams wurden zusammengestellt und min. ein Pilot-Team startet mit dem Experiment.

Weitere Bestandteile dieser Phase:

  • Lösung-Ursache-Matrix
  • Soll-Prozessdarstellung
  • Personalplan / Team-Zusammenstellung
  • Implementierungsplan

Nur nicht nachlassen – die Control-Phase

Die Einführung der agilen Methoden war schwer. Doch der richtig schwere Teil folgt nun: die Prozesse müssen beibehalten und weiter optimiert werden.

In der Improve-Phase finden dazu regelmäßig Audits statt, um den aktuellen Prozess zu verifizieren.

Eine (unvollständige) Checkliste

Nun kommt sie doch: eine Checkliste zur Einführung von agilen Methoden im Unternehmen. Die Checkliste ist allerdings unvollständig und dient als Wegweiser für die ersten Gehversuche.

Eine wichtige Frage, die ganz am Anfang gestellt werden sollte, ist:

Warum wird ausgerechnet SCRUM eingeführt?

Dahinter verstecken sich die Fragen:

  • Wird SCRUM eingeführt, weil es gerade jeder macht?
  • Kommt es vom Management oder von den Teams?
  • Und wurde auch verstanden, für was SCRUM steht und welche Auswirkungen eine agile Arbeitsweise haben wird?
  • Muss es unbedingt SCRUM sein oder wird vielleicht eher ein für das Unternehmen passender Prozess gesucht – unabhängig davon, ob dieser jetzt SCRUM, Kanban oder sonstwie heißt?

Weitere Fragen zur Einführung von agilen Methoden:

  • Wie viele Mitarbeiter sind von der Umstellung betroffen?
  • Wie viele Teams gibt es bisher?
  • Welches Vorwissen existiert bereits?
  • Welche Schulungen gab es bisher?
  • Wie reagieren die Mitarbeiter auf Agile? Wird es mit Freude umgesetzt? Wie viel Zweifel ist zu hören?
  • Gibt es eine zentrale Stelle (Wiki o.ä.) wo solche Informationen gesammelt werden?
  • Wie sieht die aktuelle Projektstruktur aus? Und wie sehen die Ziele in Zukunft aus?
  • Gibt es bereits ein Definition of Done? Was ist aus Sicht des Unternehmens zwingend notwendiger Bestandteil?
  • Scrum of Scrum wird bereits eingesetzt?
  • Chief Product Owner / Company Product Owner vorhanden?
  • Organisation versteht Scrum / Agiles Projektmanagement?
  • Stehen in den nächsten 6 bis 8 Wochen wichtige Termin an, die gehalten werden müssen?
  • Gibt es bereits Testautomatisierung?
  • Finden regelmäßige Auslieferungen statt?

Und wie helfen die Fragen bei der Einführung?

Die zuvor genannten Fragen dienen als ersten Ansatzpunkt zum Start der Evaluierung. Ziel dieser Analyse ist es herauszufinden, ob agile Methoden der richtige Ansatz sind und SCRUM eingesetzt werden kann. Doch wie bereits erwähnt stellen diese Fragen nur die ersten Weichen.

Wir bieten Ihnen eine kostenlose Erstberatung zur Einführung von SCRUM in Ihrem Unternehmen an.

Inhouse-Schulung Scrum

Bei der „Inhouse-Schulung Scrum“ wird das Scrum-Framework praxisnah ohne den Einsatz von Powerpoint, dafür mit Whiteboard, Flipchart und Post-Its vermittelt. So entsteht ein vollkommen interaktiver Workshop, der die SCRUM-Inhalte nicht nur theoretisch erklärt. Sie werde mit einbezogen in den Workshop und können so die Arbeitsweise eines SCRUM-Teams hautnah erleben.

Maßgeschneiderte Inhalte

Die Inhalte können Sie selbst steuern – die Inhouse-Schulungen werden auf Ihre Bedürfnisse hin abgestimmt. Auch der Zeitplan und die Dauer der Schulungen richtet sich nach Ihnen und Ihren Mitarbeitern. Möchten Sie lieber früh am Morgen beginnen oder den Workshop gar auf ein Wochenende legen? Gar kein Problem! Wir richten uns ganz nach Ihnen.

Agile Raumbelegung

Wenn Sie keinen Raum für die Schulung zur Verfügung haben, dann unterstützen wir Sie bei der Suche nach einem optimalen Raum. Dies kann bei Ihnen in der Umgebung sein oder auch weiter weg. Dann können Sie die Inhouse Schulung Scrum gleich mit einem Firmenausflug kombinieren. Auf Wunsch bringen wir sogar eigenes Meeting-Equipment mit.

Teilnehmerkreis für Inhouse Schulung SCRUM

Die Inhouse-Schulung Scrum eignet sich für Scrum Master, Scrum Development Team-Member, Product Owner, Führungskräfte, Projektleiter, Produktmanagern und Business Analysten. Sie richtet sich an alle, die Scrum selbst einsetzen (werden) oder die in Kontakt mit Scrum-Teams stehen.


Sie sind sich unsicher, ob eine Inhouse Schulung das ist, was Sie suchen? Nutzen Sie unser Angebot und vereinbaren Sie einen kostenlosen Telefontermin zur Erstberatung.

Der Termin zur Erstberatung ist für Sie kostenlos. Wir werden gemeinsam eruieren, ob Ihnen eine Inhouse Schulung weiterhilft und welchen Bedarf Sie genau haben. Sie werden am Telefon keine weiteren Verpflichtungen eingehen müssen.

Sofern Sie sich eine Inhouse Schulung mit uns vorstellen können, werden wir im Anschluss ein auf Sie zugeschnittenes unverbindliches Angebot erstellen, dass Sie per E-Mail erhalten werden.

Sie möchten direkt ein Angebot ohne vorherige Beratung? Auch das ist natürlich möglich. Ein paar Informationen zu Ihrem Vorhaben benötigen wir allerdings. Nutzen Sie dazu bitte unser Kontaktformular: https://agile-pm.de/kontakt/

LeSS Lego Scrum

In meinem letzten Workshop Agiles Projektmanagement am Beispiel von Scrum an der VHS Wiesbaden habe ich das Lego Scrum-Spiel erweitert, so dass es zwei Teams mit einem gemeinsamen Backlog gegeben hat, die zusammen einen Zoo gebaut haben. Die Teams haben dabei das LeSS-Framework eingesetzt, um skaliert arbeiten zu können.

Ich denke, dass sich die Ergebnisse sehen lassen können. 😉

Was ist Less?

Mit Hilfe von LeSS gelingt es mehreren Teams parallel an einem Backlog arbeiten zu können. In der Übung gab es zwei Teams mit einem gemeinsamen Product Owner.
Das Sprint Planning 1 haben beide Teams gemeinsam mit dem Product Owner durchgeführt. Beim Sprint Planning 2 hingegen agierten die Teams eigenständig.
In der anschließenden Iterationsphase und den Daily Scrums waren die Teams jeweils unter sich und haben sich erst zum Sprint Review wieder zusammengefunden.
Die Sprint Retrospektive hat wieder jedes Team für sich alleine durchgeführt.

Als Besonderheit gab es neben einem Product Owner auch nur einen Scrum Master, der zwischen den beiden Teams hin und her wechseln musste.

Die Spieldefinition

Rahmen:

  • einfacher Workflow (Sprint Planning, Daily, Sprint Review, Sprint Retrospective)
  • keine Schätzungen durchführen
  • mehrere Teams mit gemeinsamen Backlog
  • je 2 Teams ein Scrum Master
  • 1 Product Owner

Zeiten:

  • Sprint Planning 3 Minuten
  • Daily Stand-up alle 3 Minuten für jeweils 1 Minute
  • Sprint Review 5 Minuten
  • Sprint Retrospektive 2 Minuten
  • 3 Sprints a 7 Minuten

Ablauf:

  • zwei Teams (od. mehr) erstellen und Arbeitsbereich einrichten 5 Minuten
  • Projektbekanntgabe 10 Minuten
    • Teams arbeiten an gemeinsamen Ziel
    • das Projekt heißt „Zoo“
    • Hauptmaterial ist Lego, anderes Material ist zugelassen
  • Backlog erstellen 15 Minuten
    • auf Flipchart die vorher erstellen Stories hängen und erklären
    • Rückfragen klären
  • Durchführung der Sprints 55 Minuten

Sprint 1 (19 Minuten)

PLANNING -> 2 -> DAILY -> 3 -> DAILY -> 2 -> REVIEW -> RETRO

Sprint 2 (19 Minuten)

PLANNING -> 2 -> DAILY -> 3 -> DAILY -> 2 -> REVIEW -> RETRO

Sprint 3 (17 Minuten)

PLANNING -> 2 -> DAILY -> 3 -> DAILY -> 2 -> REVIEW

Retro anschließend (10 Minuten):

  • wie fühlt es sich an, in einem Scrum-Team zu sein?
  • wie liefen die Sprints?
  • was würde geändert werden, wenn das Spiel nochmals gespielt werden würde?
  • was waren die Aufgaben des PO?

Die Spieldauer wird in etwa 95 Minuten zzgl. Pausen betragen.