Definition of Ready

© Software Quality Lab www.software-quality-lab.com
Quality Gate für das agile Requirements Engineering
Markus Unterauer
Berater, Trainer
Definition of Ready
- 1 -

Die Realität in vielen agilen Projekten
- 2 -
Stories werden
im Sprint nicht
fertig (Spillover)
Viele grobe
Änderungen
während des Sprints
Am Ende trotzdem
ein nicht gebrauchs-
taugliches Produkt
Umsetzung trifft
Erwartung des
Kunden nicht
Viele Iterationen, bis
eine Funktion passt

Ursache sind oft unreife Backlog Items
- 3 -

Ein Beispiel aus der Praxis
- 4 -
Klar?
Klein
genug?
Durchdacht?
Realistisch?
Eindeutig?
Konsistent?
Vollständig?

Wir brauchen eine vereinbarte Mindestqualität!
- 5 -
Definition of Ready

= Quality Gate für das Backlog
 Vereinbarung, was an Vorarbeit geleistet
werden muss, bevor Umsetzung startet
 Zwischen Product Owner und Team
vereinbart
Dadurch höhere Effizienz, weil …
 Weniger Iterationen, bis Erwartungen
erfüllt sind
 Weniger Rückfragen (und es kommen
doch eh immer dieselben Fragen…)
- 6 -
Definition of Ready (DoR)

Unterschiedliche Definitions of Ready
- 7 -
1. Wann ist eine Idee reif
fürs Product Backlog?
 DoR für Ideen am Eingang ins Backlog
2. Wann ist ein Epic reif
fürs Release Backlog?
 DoR für Epics am Eingang ins Release-
Backlog
3. Wann ist eine Story reif
fürs Sprint Backlog?
 DoR für Stories am Eingang ins
Backlog

Ablauf in agilen Projekten
- 8 -
Idee
Sprint
Backlog
Release
BacklogProduct
Backlog
Product
Increment
Release
Planung
Sprint
Planung
Umsetzung
Produkt
Planung

Quality Gates
- 9 -
Idee
Sprint
Backlog
Release
BacklogProduct
Backlog
Product
Increment
Release
Planung
Sprint
Planung
Umsetzung
Produkt
Planung
Definition of Ready Definition of Done

Eine DoR sollte alle Informationen einfordern,
sodass das Team …
 die Anforderung und deren Sinn
verstehen,
 den Aufwand schätzen,
 Risiken erkennen und
 die nächsten Schritte planen
kann.
- 10 -
Was sollte eine DoR enthalten?

For us a Story is ready for Sprint Backlog, when …
 At least one real usage scenario is provided.
 The Item is estimated by the team.
 The User Story template is applied correctly.
 There are no open critical questions.
 Technical concept attached (if appropriate).
 UI mockups are attached (if appropriate).
 Logical data model provided (if appropriate).
 An impact and risk analysis done.
 Also non-functional requirements are discussed.
 Assumptions discussed and visible.
 Acceptance criteria are defined and agreed
 Story was checked for KISS and INVEST criteria.
- 11 -
Ein Beispiel aus dem echten Leben

Für ein Backlog Item muss
folgendes definiert sein:
 Dringlichkeit
 Priorität
 Komplexität
 Business Value
 Kundennutzen
 Märkte
 Nicht-Ziele
 Testbarkeit
 Nicht-funktionale Anforderungen
 Ressourcen
 Sicherheitskritisch
- 12 -
Ein weiteres Beispiel aus dem echten Leben

Was macht gute Anforderungen aus?
- 13 -

Independent – unabhängig
Negotiable – verhandelbar, diskutierbar
Valuable – wertvoll für den Kunden
Estimatable – Aufwand abschätzbar
Small – in einem Sprint umsetzbar
Testable – definierte Abnahmekriterien
- 14 -
Gute User Stories sind ein INVESTment

Wie groß sollten Backlog Items sein?
- 15 -
 Epic  in einem Release umsetzbar
 User Story  sprintable = in einem Sprint umsetzbar
 Keine Story größer als die halbe Velocity
3 - 10 Stories je Sprint

 Hinweise auf problematische Formulierungen
- 16 -
Requirements Smells
„If it smells, change it“

 Manche Substantive sind unscharf und
nur im Kontext klar.
 Auch Substantive beinhalten Gefahren
der unvollständigen Spezifikation.
- 17 -
Nicht eindeutige Substantive
Nominalisierung
Substantive ohne
Bezugsindex
Universal-
quantoren
Unvollständig
spezifizierte
Bedingungen
Unvollständig
spezifizierte
Prozesswörter
Mehrdeutige
Adjektive und
Adverbien
Unspezifische
Pronomen
Komparative und
Superlative
„Das System soll dem Anwender die Daten am Display
anzeigen.“
„Das System soll dem Anwender die Daten am Display
anzeigen.“

 Universalquantoren stellen Häufigkeiten
dar.
 Es wird eine Menge von Objekten zu
einer Gruppe zusammengefasst, für die
das gleiche Verhalten gilt. Oft gibt es aber
Ausnahmen.
 Hinweise: nie, immer, kein, nichts, alle, …
- 18 -
Universalquantoren
Nominalisierung
Substantive ohne
Bezugsindex
Universal-
quantoren
Unvollständig
spezifizierte
Bedingungen
Unvollständig
spezifizierte
Prozesswörter
Mehrdeutige
Adjektive und
Adverbien
Unspezifische
Pronomen
Komparative und
Superlative
„Nach Abschluss einer Transaktion sollen alle
Protokolldaten gelöscht werden.“
„Nach Abschluss einer Transaktion sollen alle
Protokolldaten gelöscht werden.“

 Adverbien und Adjektive werden
verwendet um Substantive oder
Prozesswörter zu beschreiben.
 Sie sind aber oft unklar und nicht prüfbar.
- 19 -
Mehrdeutige Adjektive und Adverbien
Nominalisierung
Substantive ohne
Bezugsindex
Universal-
quantoren
Unvollständig
spezifizierte
Bedingungen
Unvollständig
spezifizierte
Prozesswörter
Mehrdeutige
Adjektive und
Adverbien
Unspezifische
Pronomen
Komparative und
Superlative
„Ist die Bandbreite zu gering, muss möglichst sofort auf
eine angemessene Backupleitung umgeschaltet
werden.“
„Ist die Bandbreite zu gering, muss möglichst sofort auf
eine angemessene Backupleitung umgeschaltet
werden.“

 Komparative und Superlative sind
Steigerungsformen.
 Bei Vergleichsausdrücken ist oft der
genaue gewünschte Wert unklar.
- 20 -
Komparative und Superlative
Nominalisierung
Substantive ohne
Bezugsindex
Universal-
quantoren
Unvollständig
spezifizierte
Bedingungen
Unvollständig
spezifizierte
Prozesswörter
Mehrdeutige
Adjektive und
Adverbien
Unspezifische
Pronomen
Komparative und
Superlative
„Das System muss schneller funktionieren als vorher, die
Benutzbarkeit muss dabei trotzdem am größten sein.“
„Das System muss schneller funktionieren als vorher, die
Benutzbarkeit muss dabei trotzdem am größten sein.“

Viel Arbeit für den Product Owner
- 21 -
Das ist ja schon ganz
schön viel Arbeit!
Das Team hat für seine Arbeit
ein Taskboard. Warum hab
ich da eigentlich nichts?!

Requirements Board macht Arbeit des PO sichtbar
- 22 -
Ein Requirements Board hilft, die Arbeiten des Product Owners
an den Anforderungen zu visualisieren und zu managen.
Todo Preparation Discuss
w/Team
Spike ReadyEstimation

Zusammenfassung
- 23 -
 Die Definition of Ready
ist eine Checkliste
für Qualität und Inhalt
von Backlog Items.
 Die Qualität von Backlog
Items sollte systematisch
geprüft und verbessert
werden.
 Die Arbeit des PO kann
man auf einem
Requirements Board
sichtbar machen.

© Software Quality Lab www.software-quality-lab.com - 24 -
Markus Unterauer
Berater und Trainer
[m] markus.unterauer@software-quality-lab.com
Software Quality Lab
[w] www.software-quality-lab.com
Über den Vortragenden
Buch „Workshops im Requirements Engineering“
 Wie gestalte ich Workshops zur Ermittlung der Anforderungen?
 Wie moderiere ich Meetings und Workshops?
 Womit fange ich an? Was mache ich in den ersten Workshops?
Inklusive Best Practices und Checklisten, die sofort eingesetzt werden können und
Beispiele für Workshop-Moderationspläne.

Academy | Consulting | Operational Services | Tool Expertise
INNOVATION MEETS QUALITY
Software Quality Lab
- 25 -

Definition of Ready

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Definition of Ready

Ähnlich wie Definition of Ready (20)

Mehr von Markus Unterauer

Mehr von Markus Unterauer (11)

Definition of Ready