SlideShare ist ein Scribd-Unternehmen logo
© Software Quality Lab www.software-quality-lab.com
Quality Gate für das agile Requirements Engineering
Markus Unterauer
Berater, Trainer
Definition of Ready
- 1 -
© Software Quality Lab www.software-quality-lab.com
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
© Software Quality Lab www.software-quality-lab.com
Ursache sind oft unreife Backlog Items
- 3 -
© Software Quality Lab www.software-quality-lab.com
Ein Beispiel aus der Praxis
- 4 -
Klar?
Klein
genug?
Durchdacht?
Realistisch?
Eindeutig?
Konsistent?
Vollständig?
© Software Quality Lab www.software-quality-lab.com
Wir brauchen eine vereinbarte Mindestqualität!
- 5 -
Definition of Ready
© Software Quality Lab www.software-quality-lab.com
= 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)
© Software Quality Lab www.software-quality-lab.com
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
© Software Quality Lab www.software-quality-lab.com
Ablauf in agilen Projekten
- 8 -
Idee
Sprint
Backlog
Release
BacklogProduct
Backlog
Product
Increment
Release
Planung
Sprint
Planung
Umsetzung
Produkt
Planung
© Software Quality Lab www.software-quality-lab.com
Quality Gates
- 9 -
Idee
Sprint
Backlog
Release
BacklogProduct
Backlog
Product
Increment
Release
Planung
Sprint
Planung
Umsetzung
Produkt
Planung
Definition of Ready Definition of Done
© Software Quality Lab www.software-quality-lab.com
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?
© Software Quality Lab www.software-quality-lab.com
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
© Software Quality Lab www.software-quality-lab.com
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
© Software Quality Lab www.software-quality-lab.com
Was macht gute Anforderungen aus?
- 13 -
© Software Quality Lab www.software-quality-lab.com
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
© Software Quality Lab www.software-quality-lab.com
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
© Software Quality Lab www.software-quality-lab.com
 Hinweise auf problematische Formulierungen
- 16 -
Requirements Smells
„If it smells, change it“
© Software Quality Lab www.software-quality-lab.com
 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.“
© Software Quality Lab www.software-quality-lab.com
 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.“
© Software Quality Lab www.software-quality-lab.com
 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.“
© Software Quality Lab www.software-quality-lab.com
 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.“
© Software Quality Lab www.software-quality-lab.com
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?!
© Software Quality Lab www.software-quality-lab.com
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
© Software Quality Lab www.software-quality-lab.com
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.
© Software Quality Lab www.software-quality-lab.com
Academy | Consulting | Operational Services | Tool Expertise
INNOVATION MEETS QUALITY
Software Quality Lab
- 25 -

Weitere ähnliche Inhalte

Was ist angesagt?

Boketeのグロースハック~referralはギョウザである編~
Boketeのグロースハック~referralはギョウザである編~Boketeのグロースハック~referralはギョウザである編~
Boketeのグロースハック~referralはギョウザである編~
Takuya Kato
 
User Story Mapping in Practice
User Story Mapping in PracticeUser Story Mapping in Practice
User Story Mapping in Practice
Steve Rogalsky
 
User Story Mapping, Discover the whole story
User Story Mapping, Discover the whole storyUser Story Mapping, Discover the whole story
User Story Mapping, Discover the whole story
Jeff Patton
 
Invest In Good User Stories
Invest In Good User StoriesInvest In Good User Stories
Invest In Good User Stories
Craig Brown
 
Design Spikes for the Dual-Track Agile Process
Design Spikes for the Dual-Track Agile ProcessDesign Spikes for the Dual-Track Agile Process
Design Spikes for the Dual-Track Agile Process
uxpin
 
ATDD - Acceptance Test Driven Development
ATDD - Acceptance Test Driven DevelopmentATDD - Acceptance Test Driven Development
ATDD - Acceptance Test Driven Development
Naresh Jain
 
Product Backlog Refinement with Structured Conversations - Big Apple Scrum Day
Product Backlog Refinement with Structured Conversations - Big Apple Scrum DayProduct Backlog Refinement with Structured Conversations - Big Apple Scrum Day
Product Backlog Refinement with Structured Conversations - Big Apple Scrum Day
EBG Consulting, Inc.
 
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
Kenji Hiranabe
 
Dual Track Agile Or, How I learned to stop worrying and love the scrum
Dual Track Agile Or, How I learned to stop worrying and love the scrumDual Track Agile Or, How I learned to stop worrying and love the scrum
Dual Track Agile Or, How I learned to stop worrying and love the scrum
UXDXConf
 
An introduction to agile estimation and release planning
An introduction to agile estimation and release planningAn introduction to agile estimation and release planning
An introduction to agile estimation and release planning
James Whitehead
 
What is Enterprise Agile
What is Enterprise Agile What is Enterprise Agile
What is Enterprise Agile
Kenji Hiranabe
 
User Story Mapping Workshop
User Story Mapping WorkshopUser Story Mapping Workshop
User Story Mapping Workshop
Dana Pylayeva
 
A crash course to user story mapping
A crash course to user story mappingA crash course to user story mapping
A crash course to user story mapping
Frances Place
 
User Stories
User StoriesUser Stories
User Stories
Tathagat Varma
 
Splitting User Stories
Splitting User StoriesSplitting User Stories
Splitting User Stories
DCG Software Value
 
PMI-ACP Lesson 03 Nugget 1 Agile Planning, Monitoring and Adopting
PMI-ACP Lesson 03 Nugget 1 Agile Planning, Monitoring and AdoptingPMI-ACP Lesson 03 Nugget 1 Agile Planning, Monitoring and Adopting
PMI-ACP Lesson 03 Nugget 1 Agile Planning, Monitoring and Adopting
Thanh Nguyen
 
User Story Mapping
User Story MappingUser Story Mapping
User Story Mapping
Manik Choudhary
 
Design Quality Assurance
Design Quality AssuranceDesign Quality Assurance
Design Quality Assurance
Federico Pizzutto
 
The Essence of Sprint Planning : Presented by Sprint Planning
The Essence of Sprint Planning : Presented by Sprint PlanningThe Essence of Sprint Planning : Presented by Sprint Planning
The Essence of Sprint Planning : Presented by Sprint Planning
oGuild .
 
How to Team Break Out in a PI-Planning
How to Team Break Out in a PI-PlanningHow to Team Break Out in a PI-Planning
How to Team Break Out in a PI-Planning
Joël Krapf
 

Was ist angesagt? (20)

Boketeのグロースハック~referralはギョウザである編~
Boketeのグロースハック~referralはギョウザである編~Boketeのグロースハック~referralはギョウザである編~
Boketeのグロースハック~referralはギョウザである編~
 
User Story Mapping in Practice
User Story Mapping in PracticeUser Story Mapping in Practice
User Story Mapping in Practice
 
User Story Mapping, Discover the whole story
User Story Mapping, Discover the whole storyUser Story Mapping, Discover the whole story
User Story Mapping, Discover the whole story
 
Invest In Good User Stories
Invest In Good User StoriesInvest In Good User Stories
Invest In Good User Stories
 
Design Spikes for the Dual-Track Agile Process
Design Spikes for the Dual-Track Agile ProcessDesign Spikes for the Dual-Track Agile Process
Design Spikes for the Dual-Track Agile Process
 
ATDD - Acceptance Test Driven Development
ATDD - Acceptance Test Driven DevelopmentATDD - Acceptance Test Driven Development
ATDD - Acceptance Test Driven Development
 
Product Backlog Refinement with Structured Conversations - Big Apple Scrum Day
Product Backlog Refinement with Structured Conversations - Big Apple Scrum DayProduct Backlog Refinement with Structured Conversations - Big Apple Scrum Day
Product Backlog Refinement with Structured Conversations - Big Apple Scrum Day
 
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
 
Dual Track Agile Or, How I learned to stop worrying and love the scrum
Dual Track Agile Or, How I learned to stop worrying and love the scrumDual Track Agile Or, How I learned to stop worrying and love the scrum
Dual Track Agile Or, How I learned to stop worrying and love the scrum
 
An introduction to agile estimation and release planning
An introduction to agile estimation and release planningAn introduction to agile estimation and release planning
An introduction to agile estimation and release planning
 
What is Enterprise Agile
What is Enterprise Agile What is Enterprise Agile
What is Enterprise Agile
 
User Story Mapping Workshop
User Story Mapping WorkshopUser Story Mapping Workshop
User Story Mapping Workshop
 
A crash course to user story mapping
A crash course to user story mappingA crash course to user story mapping
A crash course to user story mapping
 
User Stories
User StoriesUser Stories
User Stories
 
Splitting User Stories
Splitting User StoriesSplitting User Stories
Splitting User Stories
 
PMI-ACP Lesson 03 Nugget 1 Agile Planning, Monitoring and Adopting
PMI-ACP Lesson 03 Nugget 1 Agile Planning, Monitoring and AdoptingPMI-ACP Lesson 03 Nugget 1 Agile Planning, Monitoring and Adopting
PMI-ACP Lesson 03 Nugget 1 Agile Planning, Monitoring and Adopting
 
User Story Mapping
User Story MappingUser Story Mapping
User Story Mapping
 
Design Quality Assurance
Design Quality AssuranceDesign Quality Assurance
Design Quality Assurance
 
The Essence of Sprint Planning : Presented by Sprint Planning
The Essence of Sprint Planning : Presented by Sprint PlanningThe Essence of Sprint Planning : Presented by Sprint Planning
The Essence of Sprint Planning : Presented by Sprint Planning
 
How to Team Break Out in a PI-Planning
How to Team Break Out in a PI-PlanningHow to Team Break Out in a PI-Planning
How to Team Break Out in a PI-Planning
 

Ähnlich wie Definition of Ready

Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
Markus Unterauer
 
Specification by example
Specification by exampleSpecification by example
Specification by example
Markus Unterauer
 
Kritische app performance erfolgreich optimieren mit Bison
Kritische app performance erfolgreich optimieren mit BisonKritische app performance erfolgreich optimieren mit Bison
Kritische app performance erfolgreich optimieren mit Bison
Dynatrace
 
Die unendliche User Story - agiles Anforderungsmanagement
Die unendliche User Story - agiles AnforderungsmanagementDie unendliche User Story - agiles Anforderungsmanagement
Die unendliche User Story - agiles Anforderungsmanagement
Thomas Moedl
 
Requirements Engineering in agilen Projekten - Flexibilität ist gefordert
Requirements Engineering in agilen Projekten - Flexibilität ist gefordertRequirements Engineering in agilen Projekten - Flexibilität ist gefordert
Requirements Engineering in agilen Projekten - Flexibilität ist gefordert
GFU Cyrus AG
 
Roadshow 2018 - Camunda in der Praxis: So geht's
Roadshow 2018 - Camunda in der Praxis: So geht'sRoadshow 2018 - Camunda in der Praxis: So geht's
Roadshow 2018 - Camunda in der Praxis: So geht's
camunda services GmbH
 
Scrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für ProgrammiererScrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für Programmierer
Tobias Schlüter
 
JavaScript und trotzdem Softwerker
JavaScript und trotzdem SoftwerkerJavaScript und trotzdem Softwerker
JavaScript und trotzdem Softwerker
Dennis Wilson
 
Mit Performance-Modellierung Test- und Betriebskosten senken
Mit Performance-Modellierung Test- und Betriebskosten senkenMit Performance-Modellierung Test- und Betriebskosten senken
Mit Performance-Modellierung Test- und Betriebskosten senken
Dynatrace
 
Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?
HOOD Group
 
Webanwendungen testen
Webanwendungen testenWebanwendungen testen
Webanwendungen testenBoris Köster
 
eCATT & OpenSource - Automatisierter Test in heterogenen Systemlandschaften
eCATT & OpenSource - Automatisierter Test in heterogenen SystemlandschafteneCATT & OpenSource - Automatisierter Test in heterogenen Systemlandschaften
eCATT & OpenSource - Automatisierter Test in heterogenen Systemlandschaften
Christoph Menke
 
Next Level Unit Testing
Next Level Unit TestingNext Level Unit Testing
Next Level Unit Testing
Daniel Lehner
 
Referat: Scrum Rocks – Testing Sucks?! (reloaded)
Referat: Scrum Rocks – Testing Sucks?! (reloaded)Referat: Scrum Rocks – Testing Sucks?! (reloaded)
Referat: Scrum Rocks – Testing Sucks?! (reloaded)
Digicomp Academy AG
 
ScriptRunner - Eine Einführung
ScriptRunner - Eine EinführungScriptRunner - Eine Einführung
ScriptRunner - Eine Einführung
Heiko Brenn
 
Scrum Workshop
Scrum WorkshopScrum Workshop
Scrum Workshopmrdoubleb
 
Agile intro-90min (2007)
Agile intro-90min (2007)Agile intro-90min (2007)
Agile intro-90min (2007)
Andreas Wintersteiger
 
IT Probleme loesen
IT Probleme loesenIT Probleme loesen
IT Probleme loesen
Björn Schotte
 
OOP2017: Scrum statt Murcs - Agile Software-Entwicklung
OOP2017: Scrum statt Murcs - Agile Software-EntwicklungOOP2017: Scrum statt Murcs - Agile Software-Entwicklung
OOP2017: Scrum statt Murcs - Agile Software-Entwicklung
HEC GmbH | Ein team neusta Unternehmen
 
MURCS - Wir machen jetzt Scrum (OOP 2017)
MURCS - Wir machen jetzt Scrum (OOP 2017)MURCS - Wir machen jetzt Scrum (OOP 2017)
MURCS - Wir machen jetzt Scrum (OOP 2017)
Ulf Mewe
 

Ähnlich wie Definition of Ready (20)

Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
 
Specification by example
Specification by exampleSpecification by example
Specification by example
 
Kritische app performance erfolgreich optimieren mit Bison
Kritische app performance erfolgreich optimieren mit BisonKritische app performance erfolgreich optimieren mit Bison
Kritische app performance erfolgreich optimieren mit Bison
 
Die unendliche User Story - agiles Anforderungsmanagement
Die unendliche User Story - agiles AnforderungsmanagementDie unendliche User Story - agiles Anforderungsmanagement
Die unendliche User Story - agiles Anforderungsmanagement
 
Requirements Engineering in agilen Projekten - Flexibilität ist gefordert
Requirements Engineering in agilen Projekten - Flexibilität ist gefordertRequirements Engineering in agilen Projekten - Flexibilität ist gefordert
Requirements Engineering in agilen Projekten - Flexibilität ist gefordert
 
Roadshow 2018 - Camunda in der Praxis: So geht's
Roadshow 2018 - Camunda in der Praxis: So geht'sRoadshow 2018 - Camunda in der Praxis: So geht's
Roadshow 2018 - Camunda in der Praxis: So geht's
 
Scrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für ProgrammiererScrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für Programmierer
 
JavaScript und trotzdem Softwerker
JavaScript und trotzdem SoftwerkerJavaScript und trotzdem Softwerker
JavaScript und trotzdem Softwerker
 
Mit Performance-Modellierung Test- und Betriebskosten senken
Mit Performance-Modellierung Test- und Betriebskosten senkenMit Performance-Modellierung Test- und Betriebskosten senken
Mit Performance-Modellierung Test- und Betriebskosten senken
 
Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?
 
Webanwendungen testen
Webanwendungen testenWebanwendungen testen
Webanwendungen testen
 
eCATT & OpenSource - Automatisierter Test in heterogenen Systemlandschaften
eCATT & OpenSource - Automatisierter Test in heterogenen SystemlandschafteneCATT & OpenSource - Automatisierter Test in heterogenen Systemlandschaften
eCATT & OpenSource - Automatisierter Test in heterogenen Systemlandschaften
 
Next Level Unit Testing
Next Level Unit TestingNext Level Unit Testing
Next Level Unit Testing
 
Referat: Scrum Rocks – Testing Sucks?! (reloaded)
Referat: Scrum Rocks – Testing Sucks?! (reloaded)Referat: Scrum Rocks – Testing Sucks?! (reloaded)
Referat: Scrum Rocks – Testing Sucks?! (reloaded)
 
ScriptRunner - Eine Einführung
ScriptRunner - Eine EinführungScriptRunner - Eine Einführung
ScriptRunner - Eine Einführung
 
Scrum Workshop
Scrum WorkshopScrum Workshop
Scrum Workshop
 
Agile intro-90min (2007)
Agile intro-90min (2007)Agile intro-90min (2007)
Agile intro-90min (2007)
 
IT Probleme loesen
IT Probleme loesenIT Probleme loesen
IT Probleme loesen
 
OOP2017: Scrum statt Murcs - Agile Software-Entwicklung
OOP2017: Scrum statt Murcs - Agile Software-EntwicklungOOP2017: Scrum statt Murcs - Agile Software-Entwicklung
OOP2017: Scrum statt Murcs - Agile Software-Entwicklung
 
MURCS - Wir machen jetzt Scrum (OOP 2017)
MURCS - Wir machen jetzt Scrum (OOP 2017)MURCS - Wir machen jetzt Scrum (OOP 2017)
MURCS - Wir machen jetzt Scrum (OOP 2017)
 

Mehr von Markus Unterauer

Notfallvorsorge in der Stadt - Staatliche Notfallvorsorge in Österreich
Notfallvorsorge in der Stadt - Staatliche Notfallvorsorge in ÖsterreichNotfallvorsorge in der Stadt - Staatliche Notfallvorsorge in Österreich
Notfallvorsorge in der Stadt - Staatliche Notfallvorsorge in Österreich
Markus Unterauer
 
Man kann nicht nicht planen
Man kann nicht nicht planenMan kann nicht nicht planen
Man kann nicht nicht planen
Markus Unterauer
 
Was machen unsere Anwender so? Prozessmodellierung mit BPMN
Was machen unsere Anwender so? Prozessmodellierung mit BPMNWas machen unsere Anwender so? Prozessmodellierung mit BPMN
Was machen unsere Anwender so? Prozessmodellierung mit BPMN
Markus Unterauer
 
Risikobasiertes testen
Risikobasiertes testenRisikobasiertes testen
Risikobasiertes testen
Markus Unterauer
 
Lessons learned from measuring software development processes
Lessons learned from measuring software development processesLessons learned from measuring software development processes
Lessons learned from measuring software development processes
Markus Unterauer
 
You cant control what you cant measure - Measuring requirements quality
You cant control what you cant measure - Measuring requirements qualityYou cant control what you cant measure - Measuring requirements quality
You cant control what you cant measure - Measuring requirements quality
Markus Unterauer
 
"Das Reiten eines hässlichen Pferdes ist verboten" - Gesetze aus Sicht eines ...
"Das Reiten eines hässlichen Pferdes ist verboten" - Gesetze aus Sicht eines ..."Das Reiten eines hässlichen Pferdes ist verboten" - Gesetze aus Sicht eines ...
"Das Reiten eines hässlichen Pferdes ist verboten" - Gesetze aus Sicht eines ...
Markus Unterauer
 
Tipps für Requirements Management Tools
Tipps für Requirements Management ToolsTipps für Requirements Management Tools
Tipps für Requirements Management Tools
Markus Unterauer
 
Erfolgsfaktoren im Requirements Engineering
Erfolgsfaktoren im Requirements EngineeringErfolgsfaktoren im Requirements Engineering
Erfolgsfaktoren im Requirements Engineering
Markus Unterauer
 
Software Quality Lab - Beratung und Training für mehr Qualität und Effizienz ...
Software Quality Lab - Beratung und Training für mehr Qualität und Effizienz ...Software Quality Lab - Beratung und Training für mehr Qualität und Effizienz ...
Software Quality Lab - Beratung und Training für mehr Qualität und Effizienz ...
Markus Unterauer
 
Traceability von Software Anforderungen
Traceability von Software AnforderungenTraceability von Software Anforderungen
Traceability von Software Anforderungen
Markus Unterauer
 

Mehr von Markus Unterauer (11)

Notfallvorsorge in der Stadt - Staatliche Notfallvorsorge in Österreich
Notfallvorsorge in der Stadt - Staatliche Notfallvorsorge in ÖsterreichNotfallvorsorge in der Stadt - Staatliche Notfallvorsorge in Österreich
Notfallvorsorge in der Stadt - Staatliche Notfallvorsorge in Österreich
 
Man kann nicht nicht planen
Man kann nicht nicht planenMan kann nicht nicht planen
Man kann nicht nicht planen
 
Was machen unsere Anwender so? Prozessmodellierung mit BPMN
Was machen unsere Anwender so? Prozessmodellierung mit BPMNWas machen unsere Anwender so? Prozessmodellierung mit BPMN
Was machen unsere Anwender so? Prozessmodellierung mit BPMN
 
Risikobasiertes testen
Risikobasiertes testenRisikobasiertes testen
Risikobasiertes testen
 
Lessons learned from measuring software development processes
Lessons learned from measuring software development processesLessons learned from measuring software development processes
Lessons learned from measuring software development processes
 
You cant control what you cant measure - Measuring requirements quality
You cant control what you cant measure - Measuring requirements qualityYou cant control what you cant measure - Measuring requirements quality
You cant control what you cant measure - Measuring requirements quality
 
"Das Reiten eines hässlichen Pferdes ist verboten" - Gesetze aus Sicht eines ...
"Das Reiten eines hässlichen Pferdes ist verboten" - Gesetze aus Sicht eines ..."Das Reiten eines hässlichen Pferdes ist verboten" - Gesetze aus Sicht eines ...
"Das Reiten eines hässlichen Pferdes ist verboten" - Gesetze aus Sicht eines ...
 
Tipps für Requirements Management Tools
Tipps für Requirements Management ToolsTipps für Requirements Management Tools
Tipps für Requirements Management Tools
 
Erfolgsfaktoren im Requirements Engineering
Erfolgsfaktoren im Requirements EngineeringErfolgsfaktoren im Requirements Engineering
Erfolgsfaktoren im Requirements Engineering
 
Software Quality Lab - Beratung und Training für mehr Qualität und Effizienz ...
Software Quality Lab - Beratung und Training für mehr Qualität und Effizienz ...Software Quality Lab - Beratung und Training für mehr Qualität und Effizienz ...
Software Quality Lab - Beratung und Training für mehr Qualität und Effizienz ...
 
Traceability von Software Anforderungen
Traceability von Software AnforderungenTraceability von Software Anforderungen
Traceability von Software Anforderungen
 

Definition of Ready

  • 1. © Software Quality Lab www.software-quality-lab.com Quality Gate für das agile Requirements Engineering Markus Unterauer Berater, Trainer Definition of Ready - 1 -
  • 2. © Software Quality Lab www.software-quality-lab.com 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
  • 3. © Software Quality Lab www.software-quality-lab.com Ursache sind oft unreife Backlog Items - 3 -
  • 4. © Software Quality Lab www.software-quality-lab.com Ein Beispiel aus der Praxis - 4 - Klar? Klein genug? Durchdacht? Realistisch? Eindeutig? Konsistent? Vollständig?
  • 5. © Software Quality Lab www.software-quality-lab.com Wir brauchen eine vereinbarte Mindestqualität! - 5 - Definition of Ready
  • 6. © Software Quality Lab www.software-quality-lab.com = 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)
  • 7. © Software Quality Lab www.software-quality-lab.com 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
  • 8. © Software Quality Lab www.software-quality-lab.com Ablauf in agilen Projekten - 8 - Idee Sprint Backlog Release BacklogProduct Backlog Product Increment Release Planung Sprint Planung Umsetzung Produkt Planung
  • 9. © Software Quality Lab www.software-quality-lab.com Quality Gates - 9 - Idee Sprint Backlog Release BacklogProduct Backlog Product Increment Release Planung Sprint Planung Umsetzung Produkt Planung Definition of Ready Definition of Done
  • 10. © Software Quality Lab www.software-quality-lab.com 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?
  • 11. © Software Quality Lab www.software-quality-lab.com 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
  • 12. © Software Quality Lab www.software-quality-lab.com 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
  • 13. © Software Quality Lab www.software-quality-lab.com Was macht gute Anforderungen aus? - 13 -
  • 14. © Software Quality Lab www.software-quality-lab.com 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
  • 15. © Software Quality Lab www.software-quality-lab.com 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
  • 16. © Software Quality Lab www.software-quality-lab.com  Hinweise auf problematische Formulierungen - 16 - Requirements Smells „If it smells, change it“
  • 17. © Software Quality Lab www.software-quality-lab.com  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.“
  • 18. © Software Quality Lab www.software-quality-lab.com  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.“
  • 19. © Software Quality Lab www.software-quality-lab.com  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.“
  • 20. © Software Quality Lab www.software-quality-lab.com  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.“
  • 21. © Software Quality Lab www.software-quality-lab.com 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?!
  • 22. © Software Quality Lab www.software-quality-lab.com 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
  • 23. © Software Quality Lab www.software-quality-lab.com 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.
  • 24. © 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.
  • 25. © Software Quality Lab www.software-quality-lab.com Academy | Consulting | Operational Services | Tool Expertise INNOVATION MEETS QUALITY Software Quality Lab - 25 -