Train - improuv€¦ · Inhalt! ©!improuv!GmbH!|!!! ! 1! Inhalt' Inhalt!.....!1!

Train

Scrum Kompakt

Angelika Drach, Christoph Mathis

! ! Inhalt!

©!improuv!GmbH!|!http://improuv.com!! ! 1!

Inhalt'Inhalt!................................................................................................................................................!1!1! Agile!Grundlagen!.......................................................................................................................!3!1.1! Das!Agile!Manifest!..............................................................................................................!3!1.2! Softwareentwicklung!ist!empirisch!.....................................................................................!4!

2! ScrumGKonzepte!........................................................................................................................!6!2.1! Wesentliche!ScrumGBegriffe!...............................................................................................!6!2.2! Ready!and!Done!..................................................................................................................!9!2.3! ScrumGRollen!.....................................................................................................................!10!2.3.1! Product!Owner!...........................................................................................................!10!2.3.2! Umsetzungsteam!.......................................................................................................!12!2.3.3! Der!Scrum!Master!......................................................................................................!13!2.3.4! Wo!ist!der!Projektleiter!geblieben?!...........................................................................!14!2.3.5! Und!die!Linienmanager?!............................................................................................!14!

2.4! ScrumGArtefakte!...............................................................................................................!15!2.4.1! Product!Backlog!.........................................................................................................!15!2.4.2! Der!Sprint!Backlog!......................................................................................................!17!2.4.3! Sprint!Burn!Down!Chart!.............................................................................................!18!2.4.4! Release!Burn!Down!Chart!..........................................................................................!19!

3! Agiles!Planen!und!Schätzen!.....................................................................................................!20!3.1! Arbeiten!am!Product!Backlog!...........................................................................................!20!3.1.1! Pflege!des!Product!Backlog!........................................................................................!21!3.1.2! Backlogpflege!(„Backlog!Grooming!“)!........................................................................!23!3.1.3! Technische!und!FeatureGPrioritäten!..........................................................................!24!3.1.4! Nichtfunktionale!Anforderungen!und!Restriktionen!.................................................!25!

3.2! Arbeiten!mit!User!Stories!.................................................................................................!25!3.2.1! User!Story!Format!......................................................................................................!26!

3.3! Planen!und!Schätzen!.........................................................................................................!30!3.3.1! Relative!Schätzungen!mit!Story!Points!......................................................................!33!3.3.2! Die!Kunst!des!Schätzens!.............................................................................................!34!3.3.3! Planning!Poker!...........................................................................................................!35!

4! Scrum!im!Unternehmen!..........................................................................................................!37!4.1! Organisatorische!Gründe!für!Ineffektivität!.......................................................................!37!4.2! Agile!Werte!im!Unternehmen!verankern!.........................................................................!40!4.3! Agiles!Controlling!und!Reporting!......................................................................................!41!4.4! Das!Projektgedächtnis!organisieren!.................................................................................!42!4.5! Buchhaltung!und!Abrechnung!..........................................................................................!43!

Index!...............................................................................................................................................!44!

Inhalt!

2! ! ©!improuv!GmbH!|!http://improuv.com!

!

!

!

!

!

! !

! ! Agile!Grundlagen!


!

1!Agile'Grundlagen'Agile!Strukturen!und!Entwicklungen!haben!sich!durchgesetzt,!weil!sie!nachhaltig!einige!Vorteile!für!Unternehmen!und!Entwickler!bieten.!Das!ist!eine!WinGWinGSituation!und!wenn!wir!diese!nutzen!wollen,!um!unsere!Kollegen!und!unsere!Firma!von!agilen!Arbeitsweisen!zu!überzeugen,!sollten!wir!die!Vorteile!für!beide!Seiten!parat!haben.!

In!diesem!Abschnitt!wollen!wir!über!diese!Vorteile!reden!und!die!allgemeinen!Hintergründe!etwas!ausleuchten.!

1.1! Das'Agile'Manifest'

Das!„Agile!Manifest“,!das!im!Jahr!2001!von!17!prominenten!Personen!aus!der!Softwareentwicklung!geschrieben!wurde,!beschreibt!folgende!grundlegenden!Werte!und!Prinzipien:!

Agile'Werte'

Im!Agilen!Manifest!sind!folgende!Prinzipien!als!grundlegend!aufgeführt:!!

Abbildung!1.1:!Prinzipien!im!Manifest!

!

Prozesse und Werkzeuge

umfassende Dokumentation

Vertragsverhandlungen

Planerfüllung

Individuen und Interaktionen über

überLaufende Software

überKooperation mit dem Kunden

überReaktion auf Veränderung

Agile!Grundlagen!


Ausführlicher!heißt!es:!

!! Unsere!erste!Priorität!ist!es!den!Kunden!durch!frühe!und!kontinuierliche!Lieferung!werthaltiger!Software!zufriedenzustellen!!

!! Wir!begrüßen!veränderte!Anforderungen,!auch!in!einer!späten!Entwicklungsphase.!Agile!Prozesse!nutzen!Veränderungen!als!Konkurrenzvorteil.!!

!! Häufige!Auslieferung!laufender!Software!alle!paar!Wochen!bis!alle!paar!Monate,!mit!einer!Präferenz!zu!kürzeren!Intervallen.!!

!! Anwender!und!Entwickler!arbeiten!das!ganze!Projekt!täglich!zusammen!!

!! Projekte!werden!um!motivierte!Personen!aufgebaut.!Gib!ihnen!die!nötige!Umgebung!und!Unterstützung!und!vertraue!ihnen,!ihre!Arbeit!zu!machen.!!

!! Die!effizienteste!und!effektivste!Methode!zur!Übermittlung!von!Informationen!mit!und!innerhalb!eines!Entwicklungsteams!ist!die!direkte!Kommunikation!(faceGtoGface).!!

!! Laufende!Software!ist!das!primäre!Maß!für!den!Arbeitsfortschritt.!!

!! Agile!Prozesse!fördern!nachhaltige!Entwicklung.!Sponsoren,!Entwickler!und!Anwender!sollten!kontinuierlich!ein!konstantes!Entwicklungstempo!beibehalten.!!

!! Kontinuierliche!Aufmerksamkeit!für!technische!Exzellenz!und!gutes!Design!stützt!agile!Entwicklung!!

!! Einfachheit!G!die!Kunst,!unnötige!Arbeit!zu!vermeiden!G!ist!essentiell.!!

!! Die!besten!Architekturen,!Anforderungen!und!Designs!entwickeln!sich!in!selbstorganisierenden!Teams!!

!! Das!Team!reflektiert!in!regelmäßigen!Abständen!über!die!Verbesserung!seiner!Arbeitsweise,!verbessert!sie!und!passt!sie!an.!

1.2! Softwareentwicklung'ist'empirisch'

Seit!vielen!Jahren!hat!es!eine!Menge!Bestrebungen!gegeben,!die!„handwerkliche”!und!„unkontrollierte”!Softwareentwicklung!unter!Kontrolle!zu!bringen.!Dabei!stand!das!Paradigma!der!„Industrialisierung”!im!Vordergrund!mit!dem!in!anderen!Industrien!bisher!als!unerreichbar!erscheinende!Produktivitätssteigerungen!erreicht!worden!waren.!!

Die!wesentlichen!Elemente!davon!sind:!

!! Eine!Festlegung!des!Prozesses!„von!außen”,!d.h.!die!einzelnen!Arbeitsschritte!werden!vor!der!Ausführung!festgelegt!G!in!der!Regel!von!einer!anderen!Person!als!den!Ausführenden.!

!! Aufteilung!in!viele!kleine!Einzelschritte,!die!jeder!für!sich!gut!messbar!und!kontrollierbar!sind.!!

Um!diese!Ziel!in!der!SoftwareGEntwicklung!zu!erreichen,!unternahm!man!große!Anstrengungen,!standardisierte!Prozesse!zu!entwerfen!und!zum!Teil!mit!Toolunterstützung!durchzusetzen.!Beispiele!hiefür!sind!das!VGModell,!Prince2!und!

! ! Agile!Grundlagen!


andere.!Dieser!Ansatz!hat!in!der!Softwareentwicklung!allerdings!nie!wirklich!gut!funktioniert!G!so!war!in!den!1980er!Jahren!viel!die!Rede!von!der!„Softwarekrise”.!!

So!lange!man!in!einem!relativ!stabilen!Umfeld!überschaubare!BatchG!und!ReportingGSysteme!schrieb,!konnte!man!aber!einigermaßen!über!die!Runden!kommen.!!

Mit!den!heutigen!Softwaresystemen!ist!man!damit!endgültig!an!eine!Grenze!gestoßen!und!man!kommt!nicht!mehr!umhin!anzuerkennen,!dass!Softwareentwicklung!(fast!immer)!ein!empirischer!Prozess!ist:!!

!! Heutige!Softwaresysteme!sind!wesentlich!umfangreicher.!!

!! Die!Umgebung!und!Voraussetzungen!sind!nicht!vollständig!definiert.!!

!! Anforderungen!ändern!sich!über!die!Zeit.!!

!! Das!Wissen!über!die!beste!Vorgehensweise!ist!unvollständig.!!

!! Das!System!ist!komplex.!

Abbildung!1.2:!Definierter!Prozess,!empirischer!Prozess!

In!der!Konsequenz!hängt!der!Erfolg!eines!SoftwareGSystems!von!folgenden!Prämissen!ab:!!

!! Frühes!und!häufiges!Feedback!zum!entstehenden!System!zu!bekommen,!sowohl!zu!Anforderungen!als!auch!zur!Lösung!G!z.B.!durch!frühzeitiges!und!häufiges!Demonstrieren!der!laufenden!Teillösungen!(„running!increments“).!!

!! Alle!Beteiligten!können!problemlos!Änderungen!und!neue!Erkenntnisse!reagieren!und!die!Anforderung!und!die!Lösung!anpassen.!!

ScrumGKonzepte!


!! Effektive!Kommunikation!zwischen!allen!an!der!Entwicklung!Beteiligten,!so!dass!das!geschäftliche!und!technische!Wissen!für!jeden!verfügbar!ist,!der!es!benötigt.!Oft!ist!das!effektivste!Mittel!zur!Kommunikation!das!gesprochene!Wort.!

Agile!Prinzipien!basieren!auf!diesen!Einsichten.!Daher!eignet!sich!agile!Entwicklung!für!den!allergrößten!Teil!der!Softwareentwicklung.!

2!Scrum?Konzepte'

2.1! Wesentliche'Scrum?Begriffe'

In!Scrum!gibt!es!einige!Begriffe,!die!im!normalen!Sprachgebrauch!nicht!verwendet!werden!oder!mit!etwas!anderen!Bedeutungen!verbunden!sind:!!

!Abbildung!2.1:!Scrum!Flow!

Der'Product'Owner''

hat!die!Rolle!des!Auftraggebers!bzw.!Kunden!und!trägt!die!Hauptverantwortung!für!den!geschäftlichen!Erfolg!des!zu!entwickelnden!Produkts.!Im!ScrumGProzess!ist!er!oder!sie!während!der!gesamten!Projektdauer!präsent!und!u.a.!für!die!Erstellung!und!Pflege!einer!priorisierten!Liste!offener!Features,!des!Product!Backlog!zuständig.!!

Der'Scrum'Master''

ist!der!Hauptverantwortliche!für!die!Implementierung!des!ScrumGProzesses,!d.h.!der!Organisation!der!Zusammenarbeit!mit!dem!Mitteln!von!Scrum!und!die!Einhaltung!der!

!"#$%&'()"*$+,""-.#/0"10230&45#%"6"57%899#$%&'():;'$"

<;&($"=/'>

Gift-wrap

Voucher

Cancel

Cancel

Gift-wrap

<%&#?@ABC"D00E4

Return

<%&#?@"*'2/

F&'3(;@"G2;E/'.

Voucher

H2#/I"<;&($

Return

<;&($J24@0&

K02$F&'3(;@"L>?0&

F'@0?M2//I"45#%%2+/0%&'3(;@"#?;&0$0?@"

<%&#?@"N0)#0>

N0@&'4%0;M)0

<%&#?@"G2;E/'.

<%&#?@"F/2??#?.

<;&($"N'//0?

! ! ScrumGKonzepte!


dazugehörigen!Prinzipien.!Er!oder!sie!ist!Moderator!und!Coach,!beseitigt!Hindernisse!und!stellt!sicher,!dass!das!Team!effektiv!arbeiten!kann.!!

Das'Team'oder'auch'Umsetzungsteam'

ist!nach!Scrum!das!Team!der!Programmierer,!Systemarchitekten,!Tester!und!allen!anderen!beteiligten!Softwarespezialisten!und!trägt!die!Hauptverantwortung!für!die!technische!Umsetzung!der!Anforderungen.!Dazu!gehören!die!selbstorganisierte!Entwicklungsarbeit!während!des!Sprints!und!die!Beratung!des!Product!Owner.!

Das'Scrum?Team'

Product!Owner,!Scrum!Master!und!Team!haben!ein!gemeinsames!Interesse!an!einem!Projekterfolg!–!in!ihren!jeweiligen!Rollen.!Sie!bilden!damit!auch!so!etwas!wie!ein!Team.!Um!die!beiden!TeamGBegriffe!abzugrenzen,!nennt!man!diese!alle!zusammen!das!ScrumGTeam.!

Der'Sprint'

ist!eine!meist!zweiG!bis!vierwöchige!Entwicklungsphase,!in!der!das!Team!selbstorganisiert!an!der!Umsetzung!der!für!diesen!Zeitraum!festgelegten!Anforderungen!arbeitet!und!dabei!potenziell!auslieferbare!Produktinkremente!erstellt.!!

Der'Product'Backlog'

ist!eine!priorisierte,!dynamische!Anforderungsliste!für!ein!Projekt.!Alle!Anforderungen!an!das!Umsetzungsteam!stehen!im!Product!Backlog.!Die!obersten!Einträge,!die!in!nächster!Zeit!umgesetzt!werden,!sind!detailliert,!die!späteren!können!noch!allgemeiner!formuliert!sein!und!werden!kontinuierlich!konkretisiert,!wie!sie!nach!oben!wandern.!Er!ist!Eigentum!des!Product!Owner.!

Der'Sprint'Backlog'

ist!eine!priorisierte!Liste!aller!Aufgaben!zur!Umsetzung!der!Features,!die!für!den!aktuellen!Sprint!ausgewählt!wurden!–!er!enthält!die!Aktivitäten,!die!für!den!aktuellen!Sprint!geplant!sind.!Er!ist!Eigentum!des!Teams.!

Das'Sprint'Burn'Down'Chart'

ist!die!täglich!aktualisierte!visuelle!Darstellung!der!Aufgaben,!die!das!Team!während!des!aktuellen!Sprints!noch!zu!erledigen!hat,!und!ist!ebenfalls!Eigentum!des!Teams.!

Der'Impediment'Backlog'

ist!eine!Liste!mit!Hindernissen,!die!das!Entwicklungsteam!bei!der!Arbeit!stören.!Es!wird!vom!Scrum!Master!geführt,!der!dafür!Sorge!trägt,!diese!Hindernisse!möglichst!schnell!zu!beseitigen!und!dies!mit!dem!Impediment!Backlog!transparent!macht.!

ScrumGKonzepte!


Das'Daily'Scrum'Meeting'

ist!ein!(maximal!15Gminütiges)!Zusammentreffen,!in!dem!sich!die!Teammitglieder!während!eines!Sprints!täglich!synchronisieren.!

Das'Sprintplanungs?Meeting'

vor!jedem!Sprint!ist!ein!Zusammentreffen,!in!dem!das!Team!entscheidet,!wie!viele!der!am!höchsten!priorisierten,!vom!Product!Owner!definierten!Features!es!im!nächsten!Sprint!fertigstellen!kann,!und!diese!in!technische!Aufgaben!(Tasks)!„übersetzt“.!Am!Ende!des!Meetings!steht!ein!abgestimmtes!SprintGZiel,!zu!dem!sich!das!Team!verpflichtet!(commitment).!

Das'Sprint'Review'Meeting'

am!Ende!eines!Sprints!ist!ein!Termin,!in!dem!das!Team!die!im!Sprint!umgesetzten!Features!beziehungsweise!Tasks!dem!Product!Owner!und!gegebenenfalls!weiteren!Stakeholdern!demonstriert!und!der!Product!Owner!diese!abnimmt.!

Die'Retrospektive'

ist!der!Rückblick!nach!jedem!Sprint,!in!dem!das!Team!den!Entwicklungsprozess!und!die!Zusammenarbeit!in!der!vorangegangenen!Phase!darauf!hin!analysiert,!welche!Dinge!hinderlich!und!welche!förderlich!waren.!Ziel!ist!es,!die!gewonnenen!Erkenntnisse!bereits!im!Projektverlauf!umzusetzen,!sodass!ein!kontinuierlicher!Verbesserungsprozess!entsteht.!!

!Abbildung!2.2:!Sprint!Retrospektive!

!©"improuv"GmbH""Agile"Leadership"|"h7p://improuv.com"

Lernen"O"Was"lief"gut,"was"lief"weniger"gut?

! ! ScrumGKonzepte!


2.2! Ready'and'Done'

Die!Zielsetzung,!nach!jedem!Sprint!fertige!Software!abzuliefern,!führte!in!Scrum!zu!zwei!weiteren!Fachbegriffen,!die!den!Inhalt!des!Wortes!„fertig“!etwas!genauer!definieren:!„ready„!und!„done“.!

Ready!bezieht!sich!auf!die!Anforderung:!Ein!Feature!muss!vollständig!geklärt!sein!(das!heißt:!priorisiert,!geschätzt!und!verstanden),!damit!sich!das!Team!zu!seiner!Umsetzung!verpflichten!kann.!Nur!wenn!es!in!diesem!Sinne!„ready“!ist,!darf!es!in!einen!Sprint!aufgenommen!werden.!

Done!bezieht!sich!auf!die!geschriebene!Software.!Eine!Umsetzung!ist!„done“,!wenn!sie!den!vereinbarten!Qualitätskriterien!genügt!(Definition!von!Done)!und!wenn!sie!im!Sprint!Review!präsentiert!und!abgenommen!wurde.!

Zum!Beispiel!können!Team!und!Product!Owner!vereinbaren:!Sie!muss!nachhaltig!und!beweisbar!funktionieren,!getestet!sein!und!über!eine!automatisierte!Testsuite!verfügen.!Das!kann!man!sehr!weit!treiben:!zum!Beispiel!mit!der!Forderung,!dass!das!Team!nach!jedem!Sprint!oder!sogar!nach!der!Integration!jeder!einzelnen!User!Story!lieferfähig!ist.!!

'Abbildung!2.3:!Definintion!of!Ready!and!Done!

Manche!ScrumGTeams!erstellen!spezifische!Definitionen!von!Done!auch!für!Tasks,!Sprintziele!und!Releases.!

Diese!Konzepte!stammen!ursprünglich!aus!der!„LeanGProzess“!Organisation:!bei!Übergaben!fokussiert!man!auf!perfekte!Qualität!des!übergebenen!Produkts,!d.h.!man!verlagert!eine!Eingangskontrolle!eines!Fertigungsschritts!hin!zum!Lieferanten!und!etabliert!dort!eine!Ausgangskontrolle.!Ready!und!Done!sind!solche!Übergaben:!Ready!ist!

!"#$%&'()*%%$%+

!"#$%&

,-.$-/

()*%%$%+

,-&#01"-23.-

!"#$%&'(")*+#,$",&'-"*./0+1+&'2)34)3*3")+

54,"&'3627"6",8")+&'-"+"*+"+&'3,+"-)3")+

9*")':+4)3"* ;<*73"=")>#)"*?)4$<@8,@)"6",+

5

ScrumGKonzepte!


die!Übergabe!einer!ausreichend!aufgearbeiteten!Anforderung!an!das!Team!und!Done!ist!die!Übergabe!des!integrierten!ProduktGInkrements!zurück!an!den!Product!Owner.!

2.3! Scrum?Rollen'

Scrum!beschreibt!drei!Rollen,!die!gemeinsam!dafür!sorgen,!dass!im!ScrumGProjekt!produktiv,!regelmäßig!und!zuverlässig!neue!wertvolle!Funktionalität!geliefert!wird:!!

!! Product!Owner!!

!! Umsetzungsteam!

!! Scrum!Master!

Daneben!gibt!es!noch!weitere!Personengruppen,!wie!die!Kunden,!Benutzer!,!Fachbereiche!oder!Management,!die!jedoch!in!Scrum!keine!eigene!Rollenbezeichnung!erhalten,!häufig!wird!für!diese!Personen!auch!der!Begriff!„Stakeholder“!verwendet.!

Abbildung!2.4:!Das!Scrum!Team!

2.3.1! Product'Owner'

Product!Owner!ist!immer!eine!einzelne,!konkrete!Person,!denn!nur!so!ist!gesichert,!dass!es!konsistente!Antworten!auf!Rückfragen!und!eine!eindeutige!Priorisierung!gibt.!In!größeren!Projekten!kann!er!oder!sie!aber!durchaus!ein!eigenes!Unterstützungsteam!von!Spezialisten!(Product!Owner!Team)!haben.!Möglicherweise!gibt!es!mehrere!Entwicklungsteams!mit!jeweils!einem!Product!Owner,!und!diese!bilden!selbst!ein!Team.!Ist!Letzteres!der!Fall,!ist!in!der!Regel!ein!Chief!Product!Owner!für!die!Integrität!und!die!Qualität!des!Gesamtprodukts!verantwortlich.!Und!es!bleibt!dabei:!Jedes!Entwicklungsteam!hat!genau!einen!Product!Owner!als!primären!Ansprechpartner.!Dieser!trifft!die!relevanten!Entscheidungen!über!Details!der!Anforderungen!und!deren!Priorität.!

Der!Product!Owner!

!! definiert!ProduktGFeatures!und!beantwortet!Fragen!zur!geforderten!Funktionalität,!

!! priorisiert!Product!BacklogGEinträge!abhängig!von!ihrem!geschäftlichen!Wert!und!ihrem!Risiko!und!konsolidiert!die!Anforderungen!der!anderen!Stakeholder,!!

!! entscheidet!über!ReleaseGDaten!und!den!Umfang!des!Produkts,!!

Lieferung

Scrum Master

Scrum Team

Team

Product Owner

Kunden

Benutzer

Stake Holder

! ! ScrumGKonzepte!


!! passt!die!FeatureGListe!beziehungsweise!Product!BacklogGEinträge!und!Prioritäten!vor!jedem!Sprint!an,!!

!! akzeptiert!Ergebnisse!als!„done“!oder!weist!sie!zurück,!

!! ist!verantwortlich!für!das!finanzielle!Ergebnis!des!Projekts!(engl.!„Return!On!Invest“,!ROI).!!

Unterschiede'zum'traditionellen'Auftraggeber'

Insgesamt!hat!der!Product!Owner!eine!wesentlich!aktivere!Rolle!während!der!gesamten!Projektlaufzeit!als!der!traditionelle!Auftraggeber.!Bei!Projektstart!hat!er!noch!nicht!notwendig!alle!Anforderungen!im!Detail!formuliert,!sondern!minimal!nur!die!für!die!ersten!Sprints.!Während!die!Entwickler!an!der!ersten!Umsetzung!arbeiten,!muss!der!Product!Owner!mit!Unterstützung!des!Teams!die!nächsten!Anforderungen!präzisieren.!Außerdem!ist!es!seine!Aufgabe,!für!Fragen!und!Klärungen!während!des!Sprints!zur!Verfügung!zu!stehen.!In!der!Realität!gehören!Präzisierungen!und!sinnvolle!Anpassungen,!die!sich!aus!den!Erfahrungen!während!der!Umsetzung!ergeben,!zum!ganz!normalen!Tagesgeschäft.!Keiner!erwartet,!dass!Anforderungen!unveränderlich!vollständig!definiert!sind.!!

Generell!vertraut!Scrum!im!Hinblick!auf!die!Schnittstelle!„AnfordererGEntwickler“!lieber!auf!FaceGtoGfaceGKommunikation!anstelle!von!geschriebener!Dokumentation.!Anforderungen!sind!also!bevorzugt!das!Resultat!von!Gesprächen!und!Verhandlungen!als!von!Verträgen.!Typischerweise!kommt!das!GeschäftsGKnowGhow!vom!Product!Owner,!das!technische!KnowGhow!kommt!vom!Entwicklungsteam,!gemeinsam!können!sie!dann!das!beste!Resultat!konzipieren.!

Die!zweite!Aufgabe!des!Product!Owner,!die!er!kontinuierlich!zu!erfüllen!hat,!ist!die!Abnahme!der!Ergebnisse!am!Ende!jedes!Sprints!–!im!traditionellen!Projekt!geschieht!das!oft!ganz!am!Ende!der!Projektlaufzeit.!!

Der!Product!Owner!hat!noch!eine!zweite!Sichtweise!neben!der!Arbeit!mit!dem!Team:!Er!muss!mit!verschiedenen!Stakeholdern!kommunizieren!und!eine!Gesamtsicht!des!Produktes!!herstellen,!die!in!den!linearen,!priorisieren!Backlog!eingeht.!

Normalerweise!braucht!der!Product!Owner!50!bis!100!%!seiner!Zeit!für!die!Arbeit!im!Projekt.!

Wünschenswerte'Attribute'eines'Product'Owner'

Um!seine!Rolle!adäquat!ausfüllen!zu!können,!sollte!ein!Product!Owner!Entscheidungskompetenz!bezogen!auf!das!Produkt!haben,!das!im!Projekt!realisiert!werden!soll.!Auch!hohe!fachliche!Kompetenz!ist!für!diese!Rolle!unverzichtbar:!Er!oder!sie!muss!den!Anwendungsbereich!der!künftigen!Software!gut!kennen!und!die!Konsequenzen!von!geschäftlichen!und!technischen!Entscheidungen!verstehen.!!

Generell!ist!es!nicht!ungewöhnlich,!dass!ein!Linienvorgesetzter!der!Teammitglieder!die!Rolle!des!Product!Owner!übernimmt.!Es!ist!aber!nötig,!dass!er!die!Selbstorganisation!des!

ScrumGKonzepte!


Teams!respektiert!und!seine!persönlichen!oder!Bereichsziele!nicht!im!Widerspruch!zu!den!Projektzielen!stehen.!

2.3.2! Umsetzungsteam'

Das!Team!wandelt!gemeinsam!effektiv,!regelmäßig!und!zuverlässig!Anforderungen!in!ProduktGInkremente!um.!Seine!Mitglieder!haben!mehr!Freiheiten!und!Entscheidungskompetenz!als!Programmierer!in!Softwareentwicklungsprojekten!mit!traditioneller!Steuerung.!Das!Umsetzungsteam!

!! organisiert!sich!und!seine!Arbeit!selbst,!

!! schätzt,!wie!viele!der!am!höchsten!priorisierten!Features!aus!dem!Product!Backlog!es!in!einem!Sprint!liefern!kann,!

!! verpflichtet!sich!auf!ein!SprintGZiel!(engl.!„commitment!“)!,!

!! besteht!typischerweise!aus!5!bis!9!Personen,!

!! arbeitet!in!einem!gemeinsamen!Teamraum!zusammen,!

!! verfügt!über!alle!notwendigen!Kenntnisse,!um!das!Zielprodukt!zu!liefern:!Entwickler,!GUIGDesigner,!Tester!etc.!

!Abbildung!2.5:!Teamphasen!nach!Tuckmann!

Die!TeamGMitglieder!

!! arbeiten!idealerweise!funktionsübergreifend!und!ohne!festgelegte!Rollen,!wie!Tester,!Entwickler,!Designer.!In!der!Praxis!ist!das!nicht!immer!möglich,!wir!erwarten!aber!auf!jeden!Fall,!dass!die!Teammitglieder!bereit!sind,!auch!die!Kollegen!in!Aufgaben!neben!ihrem!Spezialgebiet!zu!unterstützen.!

!! arbeiten!normalerweise!Vollzeit!im!Projekt!mit!(Ausnahmen!möglich!bei!unterstützenden!Funktionen!z.B.!für!Systemadministratoren).!!

!! wechseln!bei!Mitarbeit!in!mehreren!Teams!ihre!Zugehörigkeit!niemals!während!eines!Sprints.!

©"improuv"GmbH""Agile"Leadership"|"h7p://improuv.com"

Team"Phasen"O"Ablauf

AdjourningStormingForming

Performing

(Tuckman 1965, 1970, Bates, 1965)

Norming

! ! ScrumGKonzepte!


!! sind!kollektiv!für!die!Umsetzung!des!Commitments!und!die!Demonstration!des!ProduktGInkrements!zum!SprintGEnde!verantwortlich.!!

Scrum!beschreibt!keine!spezialisierten!Rollen!für!die!einzelnen!Teammitglieder.!Vielmehr!wird!nur!definiert,!dass!das!Team!kollektiv!für!die!Erreichung!des!versprochenen!Projektfortschritts!verantwortlich!ist.!Daraus!ergibt!sich!die!Forderung,!dass!alle!notwendigen!Fähigkeiten!im!Team!verfügbar!sein!müssen.!

2.3.3! Der'Scrum'Master'

Der!englische!Begriff!„Servant!Leader“,!ins!Deutsche!übersetzt!etwa!„dienender!Leiter“!trifft!prototypisch!auf!die!Rolle!des!Scrum!Masters!zu,!wobei!der!G!dieser!Formulierung!inhärente!G!Mangel!an!Macht!eine!Stärke!und!keineswegs!eine!Schwäche!darstellt.!Denn!das!Fehlen!einer!typischen!Chefrolle!ist!notwendige!Voraussetzung!für!das!angestrebte!hohe!Maß!an!Selbstorganisation!und!Dynamik!im!Team!und!hilft!dem!Team!dem!Scrum!Master!zu!vertrauen.!Der!Scrum!Master!hat!aber!durchaus!Funktionen,!die!den!Erfolg!des!Projekts!entscheidend!mitbestimmen.!Er!oder!sie!

!! hilft!dem!Team,!seine!Arbeit!zu!organisieren,!!

!! stellt!sicher,!dass!das!Team!funktional!und!produktiv!sein!kann,!!

!! beseitigt!Hindernisse,!!

!! schützt!das!Team!vor!externen!Störungen,!!

!! unterstützt!die!enge!Zusammenarbeit!zwischen!allen!Projektbeteiligten,!!

!! stellt!die!Einhaltung!der!ScrumGWerte!und!GPrinzipien!sicher,!

!! moderiert!Projektsitzungen,!

!! moderiert,!z.B.!bei!Entscheidungsprozessen,!Problemlösungen!und!Konflikten,!

!! führt,!leitet!an,!berät,!coacht!und!unterstützt!das!Team,!um!letztendlich!ein!selbstorganisierendes,!hochproduktives!Team!zu!werden.!

In!vielen!Fällen!unterstützt!er!auch!den!Product!Owner,!z.B.!bei!der!Bearbeitung!des!Product!Backlog!oder!beim!Anstoßen!von!notwendigen!Veränderungen!in!der!Organisation.!

Qualifikationen'des'idealen'Scrum'Master'

Er!oder!sie!ist!eine!Mischung!aus!Moderator,!Teamcoach!und!Mediator.!Der!Scrum!Master!organisiert!effektive!Meetings!und!bringt!Techniken!ein,!damit!das!Team!seine!Kreativität!entfalten!kann.!Er!hilft!dem!Team,!sich!weiter!zu!entwickeln,!und!seinen!einzelnen!Mitgliedern,!ihr!jeweiliges!Potenzial!auszuschöpfen.!Gute!Scrum!Master!schaffen!ein!Projektumfeld,!in!dem!die!Arbeit!Spaß!macht.!!

Erfahrung!in!Softwareentwicklung!ist!für!diese!Rolle!zwar!nützlich,!aber!es!gibt!auch!durchaus!erfolgreiche!Scrum!Master!ohne!tiefere!Programmierkenntnisse,!die!darauf!

ScrumGKonzepte!


schwören,!dass!ihnen!gerade!diese!Tatsache!die!nötige!Neutralität!erlaubt,!im!Team!erfolgreich!zu!moderieren.!!

Was'ein'Scrum'Master'nicht'ist'

Es!kommt!natürlich!immer!auf!die!einzelne!Person!an,!ob!und!wie!es!einem!Scrum!Master!gelingt,!verschiedene!Aufgaben!parallel!zu!verantworten.!Probleme!gibt!es!allerdings!in!den!meisten!Fällen,!wenn!der!Scrum!Master!noch!folgende!Rollen!hat:!

!! traditioneller!Projektmanager!

!! Linienvorgesetzter!von!Teammitgliedern!

!! Product!Owner!in!demselben!Projekt!

!! Vertreter!des!abwesenden!Product!Owner.!!

Alle!diese!Doppelrollen!sind!Hindernisse,!die!den!ScrumGProzess!stören!und!die!Produktivität!verringern.!Die!Rollenkombination!mit!dem!Product!Owner!ist!erfahrungsgemäß!ein!fast!unüberwindbares!Hindernis.!Denn!der!Product!Owner!stellt!tendenziell!Anforderungen,!der!Scrum!Master!hat!den!Schutz!des!Teams!als!seine!Kernaufgabe.!Selbst!wenn!eine!Person!diese!beiden!Hüte!auseinanderhalten!kann,!wie!können!die!Teammitglieder!erkennen,!welchen!Hut!er!gerade!trägt?!

2.3.4! Wo'ist'der'Projektleiter'geblieben?'

Die!Funktionen!des!klassischen!Projektleiters!oder!Gmanagers!sind!zwischen!den!beschriebenen!ScrumGRollen!aufgeteilt:!Der!Product!Owner!bestimmt!den!Umfang!und!damit!die!Lieferzeit!eines!Releases!und!durch!die!Auswahl!der!Features!auch!wesentlich!die!Produktqualität.!Der!Scrum!Master!moderiert!und!schafft!geeignete!Arbeitsbedingungen,!das!Team!organisiert!seine!gesamte!Zusammenarbeit!während!des!Produktentwicklungsprozesses.!Die!Kommunikation!nach!außen!wird!vom!Product!Owner!verantwortet,!was!aber!keinesfalls!bedeutet,!dass!das!Team!nicht!mit!Außenstehenden!reden!darf!–!es!ist!ausdrücklich!erwünscht,!auf!kurzem!Wege!zu!kommunizieren.!Zudem!treten!alle!Teammitglieder!beim!ReviewGMeeting!auf!und!berichten.!!

2.3.5! Und'die'Linienmanager?'

Scrum!konzentriert!sich!in!seinen!Aussagen!auf!das!Team!und!wie!es!seine!Arbeit!organisiert.!Doch!auch!wenn!Scrum!keine!direkten!Aussagen!über!Firmen!und!Prozesse!macht,!basieren!seine!Ideen!doch!in!einer!umfassenden!Erfahrung!mit!den!typischen!Prozessen!in!den!Unternehmen!und!üben!umgekehrt!einen!starken!Einfluss!auf!sie!aus.!Es!ist!deshalb!sehr!schwer,!ein!Projekt!mit!Scrum!zu!organisieren!und!die!dazugehörigen!Werte!zu!leben,!wenn!diese!Methode!von!der!übrigen!Organisation!bekämpft!wird.!Besonders!die!Linienmanager!müssen!ihr!Verständnis!von!„Command!and!Control“!auf!„Servant!Leader“!umstellen!und!es!dem!Team!erlauben,!selbstorganisiert!Höchstleistungen!zu!erbringen.!

! ! ScrumGKonzepte!


2.4! Scrum?Artefakte'

Scrum!beschreibt!drei!zentrale!Dokumente,!um!die!agile!Zusammenarbeit!zu!strukturieren:!

!! Product!Backlog!!

!! Sprint!Backlog!!

!! Sprint!Burn!Down!Chart!

!! Und!optional:!Release!Burn!Down!Chart.!

2.4.1! Product'Backlog'

Der!Product!Backlog!enthält!eine!vollständige,!dynamische!Auflistung!aller!Anforderungen!des!Product!Owner!in!der!Gestalt!von!Features,!die!untereinander!priorisiert!sind.!Dabei!bezieht!sich!„vollständig“!darauf,!dass!alle!Anforderungen!über!den!Product!Backlog!an!das!Umsetzungsteam!gegeben!werden.!Es!heißt!nicht,!dass!diese!schon!zu!Projektbeginn!bekannt!sein!müssen.!!

!Abbildung!2.6:!Start!eines!Projektes!

„Dynamisch“!bedeutet,!dass!immer!nur!jene!Anforderungen!detailliert!beschrieben!sind,!die!schon!bekannt!sind!und!die!kurz!vor!der!Umsetzung!stehen,!während!die!anderen!zunächst!bewusst!allgemein!gehalten!werden.!Denn!die!Detaillierung!von!Anforderungen!ist!eine!Aufgabe,!die!in!das!laufende!Projekt!gehört.!Das!aktuelle,!im!Projekt!erworbene!Wissen!soll!unmittelbar!in!die!Präzisierung!der!gewünschten!Features!einfließen,!der!Product!Backlog!wird!ständig!dynamisch!angepasst!und!mit!neuen!Erkenntnissen!aktualisiert.!!

!"#$%&'()"*$+,""-.#/0"10230&45#%"6"57%899#$%&'():;'$"

<=2&="0#>04"?&'@0A=4

Other sources

Product

BacklogPrioritize

Estimate

Vision

User

StoryUser

StoryEpic

Release

Plan

Creativity

User

centered

Design

Sprint Planning

User

StoryUser

StoryUser

Story

Product owner

TeamIdea

!"#$%&'()#%*+,%'-./#&

0/$12'!3#)4

ScrumGKonzepte!


Mike!Cohn!spricht!explizit!von!einem!so!genannten!„Produkt!Backlog!Eisberg“1,!also!einer!Form,!des!Backlogs,!die!der!eines!Eisbergs!entspricht.!Elemente,!die!ganz!oben!stehen,!also!hohe!Priorität!haben,!sollen!sehr!detailliert,!also!klein!sein,!Elemente!mit!mittlerer!Priorität!in!der!Mitte!sollen!bereits!deutlich!weniger!Details!aufweisen!und!Elemente!mit!sehr!niedriger!Prioriät!sollten!keine!Details!aufweisen.!

Zu!den!Erfahrungen,!die!den!Product!Backlog!beeinflussen!können!und!sollen,!gehören!vor!allem!Erkenntnisse!und!Anregungen,!die!sich!durch!das!Ausprobieren!der!fertigen!SoftwareGInkremente!nach!jedem!Sprint!ergeben.!Das!während!des!gesamten!Projekts!stetig!wachsende!Wissen,!wie!viel!Aufwand!bestimmte!Features!benötigen!und!wie!viel!Wert!sie!haben,!hilft!dem!Product!Owner,!den!Geschäftswert!des!Produktes!zu!optimieren.!

!Abbildung!2.7:!Ein!Beispiel!Product!Backlog!

Die!einzelnen!Features!des!Product!Backlogs!werden!in!Scrum!meist!als!„User!Stories“!formuliert,!kurze!Aussagen!aus!Sicht!des!künftigen!Nutzers,!was!das!Feature!leisten!soll:!„Ich!als!…!möchte!…!wenn!ich!…“!Der!Product!Backlog!ist!also!keine!komplette!Spezifikation,!wie!man!sie!von!traditionellen!Projekten!her!kennt.!Aber!er!ist!die!wesentliche!Schnittstelle!zwischen!dem!Product!Owner!und!dem!Team,!Grundlage!der!Arbeit!des!Teams!und!der!Diskussion!der!Beteiligten.!Die!Liste!ist!Eigentum!des!Product!Owner!und!wird!von!diesem!laufend!gepflegt!und!aktualisiert.!Das!Team!unterstützt!ihn!dabei,!indem!es!die!relative!Größe!der!Features!schätzt,!dem!Product!Owner!hilft,!Risiken!und!Abhängigkeiten!zu!erkennen,!und!damit!wesentlichen!Input!für!die!Priorisierung!liefert.!

Die!Erforschung!und!die!Realisierung!der!Anforderungen!überlappen!sich,!es!gibt!keine!getrennten!AnforderungsG!und!Realisierungsphasen.!Das!bedeutet:!

!! Anforderungen!in!Scrum!sind!„emergent“,!sie!können!während!der!Projektlaufzeit!neu!auftauchen!oder!neu!erkannt!werden.!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!11 http://www.mountaingoatsoftware.com/system/presentation/file/84/Cohn_PrioritizingYourBacklog.pdf


Den"Product"Backlog"speichern"O"Ein"Beispiel

ID Priorität Titel User Story Akzeptanz-Kriterien Schätzung (Story Points)

109 1

110 2

127 3

Auto-Versicherungs-Rabatt Als Versicherungsvertreter will ich einem potentiellen Kunden einen Rabatt anbieten, um den Abschluss zu gewinnen

Feste Liste von Rabattsätzen auswählbar (5, 10, 15%)?Rabatt in der Übersicht der Versicherungpolice dargestellt?Korrekt an den Mainframe übertragen?

5

Liste der rabattierten Verträge, die auf Genehmigung warten

Als Rabattprüfer will ich die Liste der zu prüfenden Policen sehen, damit ich mein Budget unter Kontrolle halten kann

Finanzielle Konsequenz des Rabatts sichtbar?Liste offener Rabattentscheidungen sichtbar?

3

Rabatt akzeptieren, zurückweisen oder ändern

Als Rabattprüfer will ich in der Lage sein, einen Rabatt zu genehmigen, zu verweigern oder zu verändern, um mein Budget unter Kontrolle zu halten

Akzeptiere einen Rabatt, prüfe ob korrekt in die DB eingetragenWeise einen Rabatt zurück, prüfe ob korrekt in die DB eingetragenÄndere einen Rabatt, prüfe DB

8

! ! ScrumGKonzepte!


!! Das!Team!erfährt!im!Projektverlauf!mehr!darüber,!wie!es!die!Anforderungen!des!Kunden!erfüllen!kann.!!

!! Bestehende!Anforderungen!ändern!sich.!

Physische'Formen'

Es!gibt!verschiedene!Möglichkeiten,!den!Product!Backlog!vorzuhalten:!!

!! als!eine!Sammlung!von!Karteikarten!oder!PostGIts!an!der!Wand,!!

!! auf!einem!Flipchart,!!

!! in!einem!Werkzeug!für!Anforderungsmanagement,!!

!! in!einer!Tabellenkalkulation,!zum!Beispiel!Open!Office!oder!Microsoft!Excel.!

Da!der!Product!Backlog!so!etwas!wie!die!Langzeitplanung!repräsentiert,!verwenden!viele!Teams!eine!elektronische!Form!der!Speicherung.!

2.4.2! Der'Sprint'Backlog'

Wenn!die!vom!Product!Owner!gewünschten!Features!für!den!nächsten!Sprint!gemeinsam!definiert!wurden,!entwickelt!das!Team!eine!Liste!von!Aufgaben,!die!für!die!Realisierung!notwendig!sind:!Das!Sprint!Backlog:!Was!genau!müssen!wir!tun,!um!jede!einzelne!User!Story!zu!verwirklichen?!Und!wie!viel!Zeit!werden!wir!voraussichtlich!dafür!benötigen?!!

Abbildung!2.8:!Sprint!Backlog!

Der!Sprint!Backlog!ist!Eigentum!des!Entwicklerteams,!wird!von!diesem!in!Gemeinschaftsarbeit!gepflegt,!manchmal!auch!stellvertretend!vom!Scrum!Master.!Er!ist!ein!lebendes!Dokument,!in!dem!das!gemeinsame!Zeitmanagement!des!Teams!steckt.!Denn!anhand!dieser!Liste!diskutiert!und!aktualisiert!das!Team!den!geschätzten!Restaufwand!für!die!Erreichung!des!Sprintziels.!Neu!entdeckte!Schwierigkeiten!können!dazu!führen,!dass!neue!Aufgaben!hinzukommen!oder!ursprünglich!geplante!wegfallen.!So!registriert!das!Team!tagesaktuell,!wenn!der!Zeitplan!ins!Wanken!gerät!und!kann!sofort!reagieren,!wenn!das!Sprintziel!gefährdet!erscheint.!

As a user I want ...



Test...

Develop...

Test...

Design...

Develop...

Develop...

Design...

Develop...

Develop...

Test...

Develop...

Check...

Develop...

Build...

Test...

Develop...

Test...

Develop...

Refactor...

Develop...

Develop...

Develop...

Check...

Refactor...

Test...

ScrumGKonzepte!


Aufgaben!(„Tasks“)!repräsentieren!Aufwände,!abgeschlossene!User!Stories!stellen!geschaffene!Werte!dar.!Das!spiegelt!sich!auch!in!der!Regel!wider,!dass!nur!abgeschlossene!Stories!in!einem!Sprint!Review!Meeting!präsentiert!werden.!

Verantwortlich!für!die!Umsetzung!des!Sprint!Backlogs!und!damit!für!Erreichen!des!Sprintziels!ist!immer!das!gesamte!Team.!Auch!wenn!einzelne!Aufgaben!davon!von!bestimmten!Teammitgliedern!bearbeitet!werden,!bleibt!die!Verantwortung!kollektiv.!

Was'ist'ein'guter'Task?'

Die!Formulierung!guter!Tasks!hilft!dabei,!abrechenbare!Fortschritte!in!der!Arbeit!zu!formulieren.!Dazu!hat!sich!die!eingängige!Formulierung!SMART!eingebürgert.!Ein!Task!sollte!SMART!sein:!!

!! „Specific“!G!spezifisch!genug,!damit!jeder!verstehen!kann,!was!sich!dahinter!verbirgt!!

!! „Measurable“!G!können!wir!feststellen,!ob!er!erledigt!ist?!!

!! „Achievable“!G!ist!er!(im!Sprint)!erreichbar?!!

!! „Relevant“!G!trägt!er!zur!Realisierung!der!Story!bei?!!

!! „Timely“!G!kann!man!schätzen,!wie!viel!Aufwand!seine!Realisierung!braucht?!!!!

2.4.3! Sprint'Burn'Down'Chart'

Im!Sprint!Burn!Down!Chart!visualisiert!das!Team!den!Arbeitsfortschritt!im!Sprint,!indem!es!zum!Daily!Scrum!die!aktuell!verbleibenden!Restaufwände!zur!Erreichung!des!Sprintziels!einträgt,!wobei!die!xGAchse!für!die!Zeitachse!(Tage)!während!eines!Sprints!steht.!!

Abbildung!2.9:!Sprint!Burndown!Chart!mit!zwei!Varianten!für!den!Restaufwand:!Anzahl!der!Aufgaben!und!Summe!der!Story!Points.!!!

!

Als!Maßeinheit!für!die!Restaufwände!(yGAchse)!können!für!die!Tasks!oder!die!User!Stories!geführt!werden:!

15.1 16.1 17.1 18.1 19.1 22.1 23.1 24.1 25.1 26.1

10

20

30

40

5052

47

3438

21

13

Sprint 15 - Burndown

5

10

15

20

25

17

! ! ScrumGKonzepte!


!! Die!Summe!der!restlichen!Stunden!für!nicht!abgeschlossene!Tasks!(wenn!diese!geschätzt!werden),!

!! Die!Anzahl!der!verbleibenden!Tasks,!

!! Die!Summe!der!Story!Points!der!noch!nicht!abgeschlossenen!User!Stories!(diese!Kurve!wird!typischerweise!größere!„Treppenstufen“!aufweisen!als!die!vorigen!Varianten).!

Optimal!fällt!diese!Kurve!regelmäßig!ab,!um!am!Ende!der!XGAchse!den!Wert!Null!zu!erreichen.!Sie!kann!aber!auch!einmal!ansteigen,!nämlich!dann,!wenn!sich!zeigt,!dass!das!Team!einen!Aufwand!zu!gering!eingeschätzt!hat!oder!wenn!neue!notwendige!Tasks!zu!einer!Story!entdeckt!werden.!

2.4.4! Release'Burn'Down'Chart'

Viele!Product!Owner!führen!ein!Diagramm!zu!Verfolgung!der!realisierten!User!Stories!pro!Sprint!und!zur!Releaseplanung.!Dieses!Release!Burn!Down!Chart!hat!sich!als!ein!ausgesprochen!wirksames!Hilfsmittel!erwiesen,!um!das!eigentliche!Projektziel!im!Auge!zu!behalten,!so!dass!am!Ende!tatsächlich!eine!lauffähige,!in!sich!geschlossene!Software!existiert.!!

In!diesem!Diagramm!stellt!ebenfalls!die!XGAchse!die!Zeitachse!dar,!allerdings!nicht!begrenzt!auf!die!Dauer!eines!Sprints,!sondern!für!die!mehrere!Sprints!umfassende!Releasedauer.!Die!Einheit!auf!der!xGAchse!ist!im!Gegensatz!zum!SprintGBurndown!nicht!Tage,!sondern!ganze!Sprints.!Auf!der!YGAchse!trägt!der!Product!Owner!nach!jedem!Sprint!die!Story!Points!der!noch!offenen!Features!ein.!

Abbildung!2.10:!Release!Burndown!

Das!Release!Burn!Down!Chart!wird!vom!Product!Owner!jeweils!am!Ende!eines!Sprints!aktualisiert,!um!den!aktuellen!Fortschritt!zu!spiegeln!und!eine!realistische!Planung!–!sprich!Vorhersage!über!den!weiteren!Fortschritt!auf!Basis!des!bisherigen!–!zu!machen.!


Release"Burndown

Product"Backlog"with"priori^zed"Features,"Release"BurndownSee"the"Whole"O"A"common"understanding"of"goals,"interdependencies"and"risks"helps"the"team"to"deliver"the"right"product.

Agiles!Planen!und!Schätzen!


3!Agiles'Planen'und'Schätzen'3.1! Arbeiten'am'Product'Backlog'

Ein!Product!Backlog!enthält!die!am!höchsten!priorisierten!Features!in!einem!Detaillierungsgrad,!der!ausreichend!ist,!um!sie!umsetzen!zu!können.!Die!niedriger!priorisierten!Features!werden!während!der!Projektzeit!nach!und!nach!weiter!detailliert.!Idealerweise!gehören!in!einen!Product!Backlog!nicht!Hunderte!oder!Tausende!von!Stories!–!das!verstellt!den!Blick!des!Teams!auf!die!als!nächstes!umsetzbaren.!Gleichzeitig!sollte!er!aber!dennoch!einen!Ausblick!auf!das!Gesamtprojekt!ermöglichen.!

Typischerweise!gehören!in!einen!Product!Backlog:!

!! Die!Stories!und!Items!für!den!nächsten!Sprint.!Diese!müssen!zu!Beginn!der!Sprintplanung!„Ready“!sein,!d.h.!eindeutig!priorisiert,!geschätzt!und!vom!Team!verstanden.!

!! Die!Stories,!an!denen!gearbeitet!werden!muss,!zu!denen!das!Team!noch!Rückfragen!hat,!die!technologisch!nicht!klar!sind!oder!zu!grob,!um!sie!in!einem!Sprint!abzuarbeiten.!

!! Die!Features!oder!Epics!(übergreifende!Stories),!die!noch!nicht!detailliert!oder!noch!nicht!priorisiert!sind.!

!Abbildung!3.1:!Granularitätsstufen!im!Product!Backlog!

!"#$%&'()"*$+,""-.#/0"10230&45#%"6"57%899#$%&'():;'$"

<24"#4="30&">&'3(;="?2;@/'.

A#B0"%&#'&#4#0&=0"1#4=0")'B"-BC'&30&(B.0B

D'$">&'3(;="EFB0&".0$2B2.=G"2+0&"H030&"@2BB"I300B"+0#=&2.0B

J52&2;=0&#4K@2

A$0&.0B=>&#'&#4#0&=")'$">&'3(;="EFB0&*04;5L=M="3(&;5"324"AB=F#;@/(B.4=02$

!"#$%&'()"*$+,""-.#/0"10230&45#%"6"57%899#$%&'():;'$"

*&2B(/2&#=L=44=(C0B

Fein-granular: Bereit für den nächsten Sprint.User stories.

Mittel-granular.Größere User Stories.

Grob-granular.Epics.

Prio

ritä

t

! ! Agiles!Planen!und!Schätzen!


In!einem!Backlog!sollten!dagegen!nicht!enthalten!sein.!

!! Verfeinerungen!„auf!Vorrat“:!die!Items!veralten!nicht!nur,!sondern!je!weiter!sie!in!die!Zukunft!weisen,!um!so!höher!ist!das!Risiko,!dass!sie!veraltet!sind!und!nie!umgesetzt!werden!

!! Tasks!und!Aktivitäten:!Agile!Planung!basiert!auf!der!Zerlegung!in!Features.!Aktivitäten!werden!erst!in!der!SprintGPlanung!abgeleitet!und!sind!eine!lokale!Aufgabe!des!Teams!

Ein'guter'Product'Backlog'ist'DEEP'

!! D!–!detailed!appropriately,!angemessen!detailliert!(s.!oben)!

!! E!–!estimated,!geschätzt!

!! E!–!emergent,!entwickelt!sich!im!Projekt!weiter!

!! P!–!prioritized,'priorisiert!

Im!weiteren!Verlauf!dieses!Abschnitts!beschreiben!wir,!wie!man!mit!einem!Product!Backlog!arbeitet!und!diesen!pflegt.!

3.1.1! Pflege'des'Product'Backlog'

Product!Backlogs!enthalten!die!Anforderungen!des!Product!Owners,!der!diese!mit!seinen!Stakeholdern!abgestimmt!und!eindeutig!priorisiert!hat.!Man!bezeichnet!sie!neutral!als!Backlog!Items.!Backlog!Items!können!sein:!

!! neue!Funktionalität,!bevorzugt!formuliert!als!User!Stories.!

!! Versuche,!Experimente!und!Vorarbeiten!(„spikes“),!mit!denen!man!Unsicherheit!über!das!weitere!Vorgehen!reduziert,!z.B.!einen!Durchstich!für!die!Anbindung!einer!neuen!mobilen!Plattform!an!die!Applikation.!Das!können!technische!Spikes!sein,!mit!denen!man!Unsicherheiten!über!die!Realisierung!und!Machbarkeit!beseitigen!kann!oder!funktionale!Spikes,!mit!denen!man!Funktionen!für!Kunden!testen!kann.!

!! Folgearbeiten!für!technologische!Schulden!wie!Wartungsarbeiten,!größere!Bugfixes,!Refactoring!oder!das!nachträgliche!Erstellen!von!Tests!für!bestehenden!Altcode.!

Bevorzugt!sollte!man!sich!auf!neue!Funktionalität!konzentrieren!und!Spikes!auf!das!Notwendige!begrenzen!–!sie!stellen!im!Prinzip!wieder!Arbeiten!auf!Vorrat!und!damit!potenziell!Verschwendung!im!Sinne!des!„Lean“!Ansatzes!dar.!Gute!Spikes!sollten!auf!jeden!Fall:!

!! Schätzbar!sein!–!im!Notfall!muss!man!mit!einer!Timebox!zur!Begrenzung!des!Aufwands!arbeiten!

!! Demonstrierbar!sein!–!sie!sollten!ein!abrechenbares!Ergebnis!liefern!

!! Akzeptierbar!sein!–!eine!Entscheidung!über!die!Zielerreichung!ermöglichen.!



In!manchen!Umgebungen!ist!es!ausreichend,!die!User!Stories!zu!formulieren!und!in!den!Product!Backlog!einzutragen.!In!anderen!Fällen,!z.B.!bei!komplexen!Produkten!oder!hohem!Regulierungsbedarf,!braucht!der!Product!Owner!mehr!Unterlagen.!Der!Product!Backlog!ist!dann!nicht!Ersatz!für!jegliche!Spezifikation!bzw.!eine!saubere!Produktplanung.!Dann!besteht!nach!wie!vor!die!Notwendigkeit,!Kundenwünsche!zu!erfragen,!sie!abzubilden!und!zu!dokumentieren.!

Abbildung!3.2:!Good!Bye!Eisernes!Dreieck!!!

Für!den!Product!Owner!heißt!das!je!nach!Projekt!und!Zielgruppe,!andere!Dokumente!zu!pflegen,!die!Features!in!User!Stories!zu!zerlegen!und!in!eine!eindeutige!Reihenfolge!zu!bringen.!

Wichtig!für!das!Team:!

!! Der!Product!Backlog!ist!die!zentrale!Schnittstelle!zum!Product!Owner.!Die!am!höchsten!priorisierten!Product!Backlog!Einträge!müssen!weit!genug!vorbereitet!sein,!damit!sie!verlässlich!umsetzbar!sind.!

!! Das!Team!unterstützt!den!Product!Owner!beim!Schätzen!und!beim!Aufteilen!der!Produktfeatures!in!Stories,!die!in!einem!Sprint!umsetzbar!sind.!

!! Das!Team!weist!auch!auf!Unklarheiten!und!technische!Unsicherheiten!in!den!Product!Backlog!Items!hin.!Das!kann!dazu!führen,!dass!man!einen!Prototyp!oder!Spike!(Machbarkeitsstudie)!baut,!um!ein!Feature!oder!eine!vorgesehene!Lösung!genauer!beurteilen!zu!können.!Umgekehrt!kann!auch!der!Product!Owner!einen!Spike!anfordern,!um!Optionen!für!Features!zu!sehen!oder!sie!mit!Kunden!durchzusprechen.!

!! Das!Team!hat!auch!die!Aufgabe,!auf!technologische!Schulden!hinzuweisen!und!Zeit!für!Umbauten!oder!Refactoring!einzufordern,!wenn!diese!vorhanden!sind.!Es!kennt!das!Softwaresystem!am!besten!und!kann!daher!oft!exklusiv!die!Notwendigkeiten!zur!Sicherung!der!inneren!Produktqualität!erkennen!und!formulieren.!Selbstverständlich!ist!der!richtige!Weg,!erst!gar!keine!technischen!Schulden!aufzubauen!–!aber!oft!hat!man!eine!Vergangenheit!zu!bewältigen.!


Source:"Dean"Leffingwell

Requirements

Resources

DateResources

Date

Waterfall/Tradi^onal Agile

PlanDriven

ValueDriven

Requirements

Fixed

Es^mated



!! Das!direkte!Gespräch!(„face!to!face“)!ist!durch!nichts!zu!ersetzen.!Voraussetzung!für!die!Umsetzung!ist,!dass!das!Team!die!Anforderung!verstanden!hat.!Das!kann!oft!nur!in!einem!Gespräch!erreicht!werden!und!die!Diskussion!kann!eine!umfangreiche!fehlerträchtige!Spezifikation!überflüssig!machen.!

3.1.2! Backlogpflege'(„Backlog'Grooming'“)''

Es!ist!notwendig,!das!Product!Backlog!regelmäßig!zu!verfeinern,!Stories!aufzuteilen!und!zu!schätzen.!Diese!regelmäßige!Product!Backlog!Pflege!nennt!man!im!Englischen!!„Product!backlog!grooming“.!

Viele!Teams!liefern!die!Unterstützung!bei!der!Product!Backlog!Pflege!in!regelmäßigen,!z.B.!wöchentlichen!AnforderungsGWorkshops.!Diese!sollen!sicherstellen,!dass!zu!Beginn!jeden!Sprints!die!höchst!priorisierten!Features!ausreichend!detailliert!und!vorbereitet!sind.!!

Abbildung!3.3:!Backlog!Grooming!

Der!große!Nutzen!dieser!Workshops!ist:!

!! Sie!finden!regelmäßig!statt,!sind!also!berechenbar!in!den!Arbeitsablauf!einzuplanen.!

!! Sie!sind!fokussiert!auf!jeweils!wenige!neue!Features!oder!Stories.!

!! Wenn!offene!Fragen!auftreten,!kann!man!die!Stories!bis!zur!Klärung!vertagen!und!nochmals!bearbeiten!–!anders!als!bei!der!Sprintplanung,!in!der!nur!in!


Sprint

Review Meeting

PlanningMeeting

Retrospektive

Ready- understood- estimated- prioritized

Done- implemented- tested- integrated

User storiesshippable

product increment

5

Backlog Grooming Meeting

5

- refine- split- estimatenew Stories


PrioriMzaMon"criteria:"risk"&"value

Risk

Valu

e

highlow

low

high

12

3 ?



Ausnahmefällen!geschätzt!werden!sollte.!Schlimmstenfalls!besteht!beim!Sprint!Planning!der!Druck,!sofort!mit!der!Umsetzung!zu!beginnen,!auch!wenn!noch!zu!viel!unklar!ist.!

!! Es!muss!nicht!immer!das!ganze!Team!teilnehmen!–!wobei!hier!zu!beachten!ist,!dass!die!Einbeziehung!der!übrigen!Teammitglieder!dann!in!der!Sprintplanung!erfolgen!muss!und!dies!dann!zusätzlichen!Zeitaufwand!bedeutet.!

Agile!Teams!arbeiten!typischerweise!sehr!fokussiert!und!intensiv.!Während!das!ungeahnte!Reserven!in!der!Produktivität!freisetzen!kann,!führt!es!manchmal!dazu,!dass!sich!die!Teammitglieder!auf!die!nächstliegenden!Aufgaben!konzentrieren.!Ein!regelmäßiger!Blick!auf!den!größeren!Zusammenhang!bekämpft!auch!den!Tunnelblick,!unter!dem!manche!Teams!leiden!und!kann!ihnen!helfen,!die!Perspektive!auf!die!Produktvision!präsent!zu!halten.!

3.1.3! Technische'und'Feature?Prioritäten'

Mancher!Product!Owner!wird!tendenziell!dazu!neigen,!Aufwände!für!rein!technische!Verbesserungen!oder!Refactoring!zu!verschieben!und!kurzfristige!Interessen!zu!überschätzen.!Hier!muss!das!Team!gegensteuern.!Umgekehrt!entwickeln!manche!Softwareentwicklungsteams!gerne!eine!gewisse!„künstlerische!Ader“!und!neigen!dazu,!sich!in!technischen!Spielereien!zu!ergehen!oder!die!sprichwörtlichen!goldenen!Wasserhähne!einzubauen,!bevor!das!Dach!fertig!gedeckt!ist.!Dann!wiederum!kann!der!Product!Owner!übertriebene!Höhenflüge!stoppen.!!

Abbildung!3.4:!Was!steht!im!Product!Backlog!!

Dazwischen!muss!eine!gesunde!Balance!gefunden!werden.!Ein!gutes!Diskussionsklima,!in!dem!jeder!die!Interessen!des!jeweils!anderen!versteht!und!respektiert,!hilft!einen!gesunden!Ausgleich!zu!schaffen.!

Ebenfalls!beim!Team!liegt!die!Verantwortung,!die!Systemsicht!einzubringen.!Denn!meist!verfügt!nur!das!Team,!nicht!der!Product!Owner!über!die!Kompetenz,!die!Gefahr!technologischer!Schulden!–!offene!Fragen,!unfertige!Teile!oder!schlechte!Lösungen!–!zu!erkennen!und!Maßnahmen!zu!ihrer!Vermeidung!für!den!Product!Backlog!vorzuschlagen.!Für!den!Product!Owner!sind!viele!Mängel!in!der!Programmierung!bzw.!der!


Was"steht"im"Backlog

User Stories $: Neue Funktionalität

Größere RefactoringsGrößere Bugs, technische Schulden Vergangenheit

Research, Spikes, Experimente Zukunft

+



Softwarestruktur!gar!nicht!ersichtlich,!vor!allem,!wenn!er!selbst!keine!Kenntnisse!in!der!Softwareentwicklung!hat.!Wenn!ein!Problem!aufgetreten!ist!oder!sich!bei!den!Planungen!abzeichnet,!müssen!die!Entwickler!deshalb!stellvertretend!für!externe!Stakeholder!(der!Betrieb)!oder!virtuelle!Stakeholder!(das!System)!auftreten!und!den!Product!Owner!davon!überzeugen,!die!notwendigen!Maßnahmen!einzuplanen.!!

3.1.4! Nichtfunktionale'Anforderungen'und'Restriktionen'

Zu!jedem!BacklogGEintrag!kann!es!einen!Satz!von!nichtfunktionalen!Anforderungen!und!Restriktionen!geben.!Da!solche!Anforderungen!potentiell!mehrere!Einträge!betreffen!können!(sie!bilden!eine!m:n!Relation!mit!den!Einträgen),!ist!es!sinnvoll,!diese!an!einem!zentralen!Platz!niederzuschreiben.!

Wir!schlagen!dafür!die!„Definition!of!Done“!als!zentralen!Platz!vor.!

3.2! Arbeiten'mit'User'Stories'

Eine!User!Story!ist!eine!in!Alltagssprache!formulierte!SoftwareGAnforderung.!Sie!ist!bewusst!kurz!gehalten!und!umfasst!in!der!Regel!nicht!mehr!als!zwei!Sätze.!Das!Konzept!und!die!Verbreitung!von!User!Stories!in!agilen!Projekten!hat!Mike!Cohn![Coh2004]![Coh2005]!entscheidend!beeinflusst.!Inzwischen!sind!User!Stories!ein!integraler!Bestandteil!von!Scrum!und!der!agilen!Methodik!im!Allgemeinen2.!!

In!manchen!Unternehmen!haben!sind!andere!Mechanismen!und!Formen!wie!z.B.!Use!Cases!etabliert!oder!es!sind!formelle!Pflichtenhefte!vorgeschrieben!und!allen!Beteiligten!vertraut.!Auch!unter!diesen!Vorgaben!kann!man!ein!Projekt!agil!durchführen.!Wir!finden!User!Stories!ein!faszinierendes!Konzept,!da!sie!die!Maxime,!miteinander!von!Angesicht!zu!Angesicht!zu!kommunizieren,!exemplarisch!unterstützen.!

Reichweite'einer'User'Story'

Der!Inhalt!einer!User!Story!kann!sehr!allgemein!!–!wir!sprechen!dann!von!einem!„Epos“!(engl.!epic)!oder!einem!Thema!(engl.!theme)3!–!oder!sehr!detailliert!und!spezifisch!sein.!Beide!Formen!haben!ihre!Berechtigung,!wenn!sie!im!richtigen!Kontext!verwendet!werden.!So!besteht!die!Produktvision!häufig!erst!einmal!aus!mehreren!Epen,!also!sehr!allgemeinen!Stories.!Damit!alle!Beteiligten!in!die!konkrete!Planung!einsteigen!können,!zerlegt!der!Product!Owner!dann!mit!Unterstützung!des!Teams!die!wertvollsten,!d.h.!am!höchsten!priorisierten!Epen!in!kleinere!User!Stories!und!priorisiert!wiederum!diejenigen!mit!dem!größten!Wert!oder!dem!höchsten!Risiko.!!

Epen!sind!typischerweise!eher!für!den!Kunden!und!den!Product!Owner!interessant:!Sie!repräsentieren!real!nutzbare!und!auslieferbare!Produktfeatures.!Das!Team!benötigt!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!2 http://www.scrumalliance.org/pages/what_is_scrum 3 Die Größenordnung eines Thema korrespondiert mit dem oben genannten Begriff “Feature”. Wir verwenden wahlweise beide Begriffe – in der traditionellen Entwicklung hat der Begriff einen festen Platz erobert. Wen wir diesen Begriff verwenden, reduzieren wir manchmal die Verständigungshürde mit traditionellen Projektmanagern.



kleinere!Stories,!um!mehrere!davon!in!einem!Sprint!abarbeiten!und!Ergebnisse!liefern!zu!können.!

3.2.1! User'Story'Format'

Ein!User!Story!beschreibt!ein!Szenario!und!beantwortet!dabei!die!Fragen:!Wer,!Was!und!Warum.!Ein!oft!verwendetes!Muster!sieht!so!aus:!!

!! ‘Der!…’!(wer:!Rolle)!

!! ‘möchte!…’!(was:!AnwendungsGAnforderung)!!

!! ‘weil!…’!(warum:!Nutzen,!geschäftlicher!Wert)!!

Wer'

Die!User!Story!nimmt!die!Perspektive!eines!Endnutzers!ein!und!beschreibt!eine!Forderung!aus!Sicht!einer!konkreten!Rolle.!Je!präziser!diese!formuliert!ist,!desto!besser.!!

!! Nicht!gut:!„Als!User!…“!!

!! Besser:!„Als!für!Flugbuchungen*zuständige*Sekretärin!eines!Vielfliegers!…“!!

Je!anschaulicher!die!User!Story!das!Arbeiten!des!Endnutzers!mit!dem!System!vor!Augen!führt,!desto!klarer!wird!automatisch!die!Zielrichtung.!

In!Ausnahmefällen!kann!man!bei!„Wer“!auch!ein!SoftwareGSystem!eintragen,!zum!Beispiel,!wenn!man!BackendGSysteme!entwickelt!und!keinen!menschlichen!Benutzer!hat.!Dann!beginnt!die!User!Story!z.B.!mit!der!Formulierung:!„Als!WebserviceGClientGProgramm!...“!!

Abbildung!3.5:!User!Story!Format!

!"#$%&'()"*$+,""-.#/0"10230&45#%"6"57%899#$%&'():;'$"

Struktur einer User Story

Sie beschreibt ein Szenario in den Begriffen wer, was und warum ‘Als ein …’ (Rolle: wer will etwas) ‚‘Will ich …’ (was: Anwendungs-Anforderung) ‚‘weil …’ (warum: Nutzen, geschäftlicher Wert).

Beschreibt die ersten Akzeptanzkriterien um den Kontext und Umfang deutlich zu machen.

Diese können den Anfangspunkt für das Schreiben von Akzeptanztests bilden

!"#$%&'()"*$+,""-.#/0"10230&45#%"6"57%899#$%&'():;'$"

User Story: Formatvorschlag

StoryRolle

Inhalt

Geschäfts-Ziel

Größe



Was'

Wichtig!ist,!dass!ein!klares!Szenario!beschrieben!wird,!und!zwar!ein!geschäftliches!Szenario!und!nicht!eine!technische!Lösung!(das!wäre!ja!ein!„Wie“).!!

!! Nicht!gut:!„…!möchte!ich!ein!System,!das!Prioritäten!im!Hinblick!auf!Platzwahl!automatisch!speichert“.!!

!! Besser:!„!…!möchte!ich!bei!der!Flugbuchung,!dass!die!von!mir!einmal!eingegebene!Priorität!bei!der!Sitzplatzwahl!–!Fenster!oder!Gang!–!als!Voreinstellung!erhalten!bleibt,!ich!sie!aber!bei!Bedarf!verändern!kann.“!

Warum'

Dieser!Teil!der!User!Story!repräsentiert!den!geschäftlichen!Wert,!der!mit!der!Lösung!des!Problems!erzielt!werden!soll.!Er!hat!die!wichtige!Funktion,!alle!Beteiligten!auf!die!Wertschöpfung!zu!fokussieren.!In!vielen!Fällen!ist!es!auch!so,!dass!uns!als!Entwickler!oft!das!Wissen!über!die!Arbeitswelt!des!Anwenders!fehlt.!Zu!verstehen!warum!ein!Feature!gebraucht!wird,!ist!eine!wertvolle!Information,!die!meist!das!„Was“!nochmals!vertieft!oder!aufklärt.!!

!! Nicht!gut:!„…!um!mir!die!Flugbuchung!zu!erleichtern.“!!

!! Besser:!„…!damit!ich!bei!den!einzelnen!Buchungen!Zeit!spare.“!

User!Stories!kann!man!auf!eine!normale!Karteikarte,!ein!DinGA5GBlatt!oder!eine!speziell!für!ScrumGProjekte!entworfene!UserGStoryGKarte!schreiben!oder!drucken.!Es!ist!sinnvoll,!dass!das!Material!etwas!stabiler!ist!als!ein!dünnes!Blatt!Papier,!damit!die!Karte!auch!hektische!Teamsitzungen!gut!übersteht.!

Details'

Auf!der!Rückseite!der!jeweiligen!Karte!werden!die!Akzeptanzkriterien!formuliert.!Die!besten!Akzeptanzkriterien!sind!konkrete!Beispiel!von!erwarteten!Ergebnissen,!die!sich!zur!Überprüfung!eignen.!!

!! Nicht!gut!wäre!in!unserem!Beispiel:!„Die!Priorität!bei!der!Sitzplatzwahl!lässt!sich!gut!eintragen.“!!

!! Besser:!„Bei!der!ersten!Flugbuchung!werde!ich!nach!meiner!Vorliebe!bei!der!Sitzplatzwahl!fragt.!Zugleich!stellt!mir!das!System!die!Frage:!„Möchten!Sie!diese!Auswahl!für!künftige!Buchungen!speichern?“!Wenn!ich!hier!mit!„Ja“!antworte,!ist!die!Priorität!bei!der!nächsten!Flugbuchung!voreingestellt.!Es!gibt!jedoch!den!Button:!„Platzauswahl!ändern.“!

Die!Akzeptanzkriterien!bilden!oft!den!Anfangspunkt!für!das!Schreiben!von!Akzeptanztests,!die!nachweisen!müssen,!dass!die!User!Story!wie!erwartet!implementiert!ist.!Oft!wird!erst!durch!diese!klar,!welcher!Aufwand!hinter!einer!Benutzergeschichte!steht!oder!welche!Granularität!sie!verlangt.!Es!kann!sich!z.B.!herausstellen,!dass!der!Product!Owner!viel!mehr!erwartet,!als!das!Team!auf!den!ersten!Blick!sieht.!!



Manchmal!nimmt!man!auch!nichtfunktionale!Eigenschaften!in!die!Liste!der!Akzeptanzkriterien!auf.!Man!sollte!sich!dann!auch!überlegen!

!! ob!sich!eine!klare!Formulierung!finden!lässt,!die!einfach!zu!überprüfen!ist.!Z.B.!ist!die!Formulierung!„wenn!ich!eine!Suche!mit!folgenden!Parametern!auslöse,!habe!ich!eine!Suchzeit!von!nicht!mehr!als!1,5!Sekunden“!besser!als!„hohe!Performance!bei!der!Suche“!

!! Bei!sich!wiederholenden!Kriterien!sollte!man!auch!überlegen,!ob!man!die!Definition!of!Done!erweitert,!um!redundante!Beschreibungen!zu!vermeiden.!

In!der!ursprünglichen!Formulierung!von!Ron!Jeffries!sind!die!wesentlichen!Attribute!einer!User!Story!die!drei!„C”:!!

!! Card:!Stories!werden!traditionell!auf!Karteikarten!geschrieben.!Die!Karteikarten!können!durch!Notizen,!Schätzungen,!etc.!ergänzt!werden!

!! Conversation:!Die!Details!hinter!einer!Story!offenbaren!sich!oft!erst!während!einer!Diskussion,!wenn!sie!aus!mehreren!Blickwinkeln!betrachtet!werden!

!! Confirmation:!Akzeptanzkriterein!und!daraus!abgeleitete!Akzeptanztests!bestätigen,!dass!die!richtige!Funktionalität!implementiert!wurde.!

Abbildung!3.6:!Eine!gute!User!Story!

INVEST'–'ein'schneller'Check'für'die'User'Story'

Ob!eine!User!Story!eine!gute!Qualität!erreicht!hat,!lässt!sich!mit!einer!kurzen!Checkliste!kontrollieren.!Eine!gute!User!Story!ist:!

!! Independent,!unabhängig!und!unabhängig!von!Nutzen!–!die!Unabhängigkeit!vermeidet!Probleme!beim!Priorisieren!von!Stories.!Der!unabhängige!Nutzen!hilft!auch,!kleine!Funktionen!so!früh!wie!möglich!dem!Benutzer!zur!Verfügung!zu!stellen!und!Feedback!zu!erhalten.!

!! Negotiable,!verhandelbar!und!verhandelt!–!eine!Story!ist!ein!Katalysator!für!eine!Diskussion!und!kein!Vertrag.!Sie!sollte!also!auch!als!Grundlage!für!eine!Diskussion!


What"is"a"good"User"Story?If#in#doubt#…INVEST!

Independent#M#avoid#problems#in#priori?zing#stories

Nego?able#M#a#story#is#not#a#contract

Valuable#M#for#the#business

Es?mable#M#the#stories#build#the#basis#of#our#project#plan#through#the#product#backlog

Small#M#large#stories#should#be#decomposed

Testable#M#if#a#story#is#not#testable#maybe#it#doesn’t#have#any#real#value?


Good"Story

Independent

Negotiable

Vertical

Estimable

Small

Testable



benutzt!werden.!Eine!Story!wird!auch!dadurch!wertvoll,!dass!man!tatsächlich!über!ihre!Details!verhandelt!hat.!

!! Vertical!G!repräsentiert!ein!Stück!Funktionalität!über!die!verschiedenen!Softwareschichten!hinweg!oder!Valuable,!wertvoll!–!bringt!einen!Mehrwert!für!das!Geschäft.!

!! Estimable,!schätzbar!–!die!Stories!stellen!über!den!Product!Backlog!die!Basis!unseres!Projektplans!dar.!Mit!der!Schätzung!werden!häufig!verborgene!Anforderungen!sichtbar.!

!! Small,!klein!–!große!Stories!sollten!zerlegt!werden!damit!sie!in!Iterationen!umsetzbar!sind.!Außerdem!wächst!die!Komplexität!großer!Stories!überproportional,!mit!kleineren!Stories!kann!man!besser!auf!ein!Ergebnis!fokussieren.!

!! Testable,!testbar!–!wenn!man!eine!Story!nicht!testen!kann,!gibt!es!kein!Erfolgskriterium,!wann!die!Story!abgeschlossen!ist.!Testbarkeit!wirkt!oft!wie!ein!Katalysator!zum!Aufdecken!verborgener!Komplexität.!Deshalb!prüfen!erfahrene!Teams!auch!immer,!ob!und!wie!eine!Story!verifizierbar!ist,!bevor!sie!mit!der!Umsetzung!starten.!

Abbildung!3.7:!Eine!gute!User!Story!ist!vertikal!

Darüber!hinaus!gibt!es!einige!AntiGPatterns,!die!oft!auf!grundlegende!Mängel!in!einer!User!Story!hinweisen:!

!! Der!generische!Stakeholder:!„Als!Benutzer!will!ich...“!oder!noch!schlimmer:!„Als!Product!Owner!will!ich...“.!Das!kann!man!weder!hinterfragen,!da!dieser!allgemeine!Benutzer!sich!nicht!wirklich!ermitteln!lässt.!Darüber!hinaus!verpasst!man!die!Gelegenheit,!die!benötigten!Features!wirksam!einzugrenzen!und!zielgenau!die!Bedürfnisse!einer!Rolle!zu!implementieren.!

!! Der!unbekannte!Benutzer:!wenn!man!über!einen!Benutzer!zu!wenig!oder!gar!nichts!weiß,!ist!das!Nennen!dieses!Benutzers!in!der!User!Story!von!geringem!Nutzen.!Man!sollte!in!diesem!Fall!mehr!Zeit!investieren,!um!diesen!Benutzer!kennen!zu!lernen!–!durch!Befragung,!Beobachtung,!die!Entwicklung!von!Personas!etc.!

!! Technische!Features:!man!sollte!sich!Mühe!geben,!einen!Stakeholder!für!technische!Features!zu!finden.!Es!schützt!davor,!Infrastruktur!„auf!Vorrat“!zu!implementieren.!


Good"Story"Acceptance"Criteria


User"Stories"are"VerMcal

C/S architecture or business layers:User Stories should cover all layers

Client

WebhServer

ApphServer"

DBhServer

Presentation

Control

Application

Data"management"

Data"storage"



!! Akzeptanzkriterien!sind!nicht!testbar:!Wenn!man!aus!Akzeptanzkriterien!keine!Akzeptanztests!ableiten!kann,!könnte!das!bedeuten,!dass!die!Kriterien!nur!Platzhalter!sind!und!die!Story!nicht!wirklich!testbar!ist.!

3.3! Planen'und'Schätzen'

Planen'und'Schätzen'

Ein!wichtiger!Erfolgsfaktor!auch!bei!agilen!Projekten!ist!eine!längerfristige!Planung!die!vorausschauend!und!flexibel!ist!und!Risiken!einbezieht.!Gerade!hier!mangelt!es!oft!am!richtigen!Verständnis.!

Beispiele!für!eine!schlechte!Planung!sind:!

!! Das!falsche!Produkt!wird!entwickelt.!Mike!Cohn![Coh2005]!nennt!das!als!eine!Hauptursache!für!das!Scheitern!von!Projekten.!

!! Der!Plan!wird!nicht!auf!Features!aufgebaut,!sondern!auf!Aktivitäten.!Letztere!messen!den!getriebenen!Aufwand,!nicht!den!geschaffenen!Wert!und!sind!deshalb!keine!gute!Grundlage!für!den!Projektstatus!und!die!Erfolgsmessung.!

!! Wunschdenken!G!neue!Informationen,!Unsicherheiten!und!Risiken!werden!nicht!angemessen!berücksichtigt.!

!! Ein!Plan,!der!ein!Eigenleben!entwickelt,!bis!schließlich!seine!Einhaltung!wichtiger!wird!als!das!Produkt.!

!! Keine!oder!zu!seltene!Überprüfung!des!Plans.!

Das'richtige'Produkt'entwickeln'

Der!offensichtlichste!Fall,!dass!das!falsche!Produkt!entwickelt!wurde,!ist,!wenn!bei!der!Auslieferung!die!Features!fehlen,!die!das!Produkt!der!Konkurrenz!erfolgreich!machen.!!

Da!aber!das!Budget!so!gut!wie!immer!begrenzt!ist,!wird!die!Entscheidung!wichtig,!welche!Features!es!in!ein!Release!oder!ein!Produkt!schaffen!und!welche!außen!vor!bleiben!–!in!anderen!Worten:!auf!die!Priorisierung.!

Folgende!Faktoren!sollte!man!für!die!richtige!Priorisierung!von!Features!und!User!Stories!berücksichtigen:!

!! Technisches!Risiko!und!Unsicherheit:!Technische!Risiken!z.B.!mögliche!PerformanceGProbleme!einer!bestimmten!Lösung!sollte!man!früh!genug!kennen.!!

!! Geschäftswert!(„Business!Value“)!und!Marktrisiko!!

!! Kosten/Nutzen!Relation!eines!Features!!

!! Opportunitätskosten,!Cost!of!Delay:!Was!kostet!es,!mit!einem!Feature!zu!spät!zu!kommen.!

Für!die!Priorisierung!sind!dann!Kombinationen!dieser!Faktoren!hilfreich.!



Das!Team!spielt!eine!wichtige!Rolle!bei!der!Produktentwicklung!und!richtigen!Priorisierung!indem!es!technische!Risiken!thematisiert!und!die!Aufwände!zur!Realisierung!von!Features!schätzt.!Diese!Rolle!kann!es!umso!besser!ausfüllen,!wenn!die!Teammitglieder!über!den!Tellerrand!hinausblicken!und!sich!mit!der!längerfristigen!Planung!und!dem!Produkt!als!Ganze!auseinandersetzen.!

Die'Planung'auf'Features'aufbauen'

Die!traditionelle!Projektplanung!nutzt!eine!WorkGBreakGDownGStructure!und!Balkenpläne!(GanttGCharts)!um!die!zeitliche!Abfolge!von!Aktivitäten!zu!beschreiben!und!zu!verfolgen.!Damit!verfolgt!man!streng!genommen!aber!nicht!den!Projektfortschritt!im!Sinn!von!geschaffenem!Wert,!sondern!nach!geleistetem!Aufwand,!von!dem!man!hofft,!dass!er!mit!dem!Projektfortschritt!korreliert.!

Eine!Struktur,!die!sich!nach!Aktivitäten!gliedert!macht!eine!NeuG!und!Umplanung!ziemlich!komplex,!denn!jedes!Feature!wird!typischerweise!in!mehreren!verschiedenen!Aktivitäten!repräsentiert.!Eine!Umplanung!für!ein!neues!oder!verändertes!Feature!wird!aufwändig,!weil!man!alle!Aktivitäten!anpassen!und!bei!Änderungen!zudem!neu!prüfen!muss,!welche!anderen!Features!davon!wiederum!betroffen!sind.!

Features!als!Grundlage!der!Planung!bieten!folgende!Vorteile:!

!! Features!helfen,!die!Planung!auf!eine!wertschöpfungsorientierte!Entwicklung!und!Projektsteuerung!einzustellen.!

!! Features!erlauben!eine!einfachere!Anpassung!der!Planung!an!geänderte!Anforderungen.!

!Abbildung!3.8:!Der!Releaseplanungsprozess!

Realistisch'bleiben'

Wunschdenken!ist!in!Projekten!erstaunlich!weit!verbreitet.!Trotz!der!Erfahrungen,!dass!Entwickler!mit!steigendem!Termindruck!immer!schlechtere!Software!liefern,!wird!ständig!versucht,!unrealistische!Ziele!zu!setzen.!

Manchmal!wird!der!Product!Owner!schon!im!Vorfeld!genötigt,!zu!viel!zu!versprechen.!Es!hilft!dabei!wenig,!wenn!das!Team!diese!Illusionen!mitträgt.!Im!Gegenteil:!Je!später!die!Realität!anerkannt!wird,!desto!schmerzhafter!wird!es.!!

Wir!haben!mit!einem!agilen!Vorgehen!ein!mächtiges!Mittel!in!der!Hand,!empirische!Erkenntnisse!zum!Arbeitsfortschritt!zu!messen!und!in!die!Planung!einfließen!zu!lassen.!Die!Planung!wird!dadurch!genauer!und!zuverlässiger.!Das!Team!hat!die!Pflicht,!Fakten!zu!

!"#"$%"&'#$()(*

+,-./01)2,3.45,,6*-#",7"$8"0%9-/,:,9;/<==-./01)2>?1.,

@"0,!"#"$%"&'#$()(*%&,'01A"%%

Product Backlog füllen

Backlog Einträge schätzen

Velocity bestimmen

Release Plan erstellen



artikulieren!und!damit!zu!einer!realistischen!Planung!beizutragen!–!auch!wenn!wir!uns!dabei!manchmal!fühlen!wie!das!Kind!im!Märchen!„des!Kaisers!neue!Kleider“.!

Unrealistische!Planung!

!! führt!zu!einer!riesigen!Verschwendung,!denn!es!werden!Features!begonnen,!die!nicht!ausgeliefert!werden,!

!! führt!zu!zusätzlichem!Multitasking!und!damit!zu!Stress!und!zu!schlechteren!Resultaten,!

!! demotiviert!alle!Beteiligten!und!hindert!uns!daran,!in!einer!nachhaltigen!Geschwindigkeit!zu!arbeiten!–!der!langfristig!effektivsten!Arbeitsweise.!

Die'Planung'ist'wichtiger'als'der'Plan'

Eine!Planung!hat!immer!zwei!Effekte:!zum!einen!das!Artefakt!„Plan“,!zum!anderen!ein!genaueres!Verständnis!des!Gegenstands!bei!den!an!der!Planung!Beteiligten.!

Letzteres!ist!für!uns!der!wichtigere!Effekt,!denn!ein!genaueres!Verständnis!hat!eine!direkte!Auswirkung!auf!die!Fokussierung!der!Arbeit,!auf!die!Entstehung!neuer!Ideen!und!die!Zusammenarbeit!der!Teammitglieder.!Das!ist!auch!einer!der!Gründe,!warum!in!einem!Scrum!Projekt!alle!Teammitglieder!bei!einer!Sprintplanung!teilnehmen!müssen!–!die!vordergründige!Argumentation!mit!einer!Einsparung!von!MeetingGZeiten!hat!nur!den!Plan!als!Artefakt!im!Visier,!nicht!aber!das!während!der!Planung!aufgebaute!Wissen.!

Planung'erfolgt'während'der'ganzen'Projektlaufzeit'

Entscheidungen!sollte!man!dann!treffen,!wenn!man!möglichst!viele!Grundlagen!dafür!hat.!In!einer!Umgebung,!in!der!wir!bei!der!Arbeit!neue!Erkenntnisse!erhalten!und!in!der!sich!Anforderungen!ändern!können,!heißt!das,!so!spät!wie!möglich.!

Das!bedeutet!aber!nicht,!dass!man!immer!aufschieben!sollte:!Ab!einem!bestimmten!Punkt!braucht!man!feste!Vorgaben!fürs!weitere!Arbeiten.!Im!Lean!Thinking!nennt!man!das!den!letzten!verantwortlichen!Zeitpunkt!(„last!responsible!moment“)!für!Entscheidungen.!

In!der!Konsequenz!bedeutet!das:!

!! nach!Prioritäten!vorgehen,!

!! entsprechend!dieser!Prioritäten!die!Planung!verfeinern,!

!! während!des!ganzen!Projektes!planen.!

Planungsebenen'

Agile!Projekte!haben!im!Normalfall!zwei!wesentliche!Planungsebenen:!!

!! die!ProjektG!bzw.!Releaseplanung!und!

!! die!Sprintplanung.!



Manchmal!unterscheidet!man!die!beiden!Ebenen!auch!als!„strategische“!und!„taktische“!Planung.!

In!der!Projektplanung!versuchen!wir,!die!Entwicklung!in!auslieferfähige!Teile,!in!Releases,!zu!gliedern.!Die!Releaseplanung!deckt,!je!nach!Größe!und!Komplexität!des!Projektes!bzw.!Produktes,!eine!Periode!von!drei!bis!sechs!Monaten!ab!und!versucht,!die!Zahl!der!Sprints!für!eine!bestimmte!Menge!an!Features!vorherzusagen.!Oder!sie!hat!einen!festen!Zeithorizont!und!schätzt!die!realisierbaren!Features!ab.!!

Für!die!Vorbereitung!der!Sprintplanung!werden!die!am!höchsten!priorisierten!Features!auf!User!Stories!heruntergebrochen.!In!der!Sprintplanung!wird!das!Ziel!für!den!kommenden!Sprint!festgelegt!und!es!erfolgt!ein!Commitment!des!Teams!über!das!Sprintziel.!Dieses!Ziel!korrespondiert!mit!einer!bestimmten!Menge!von!User!Stories.!

Jetzt!werden!die!dafür!benötigten!Aktivitäten!oder!Tasks!bestimmt!–!in!der!Sprintplanung!oder!zum!Teil!erst!während!des!Sprints.!Wir!unterscheiden!dabei!die!Außensicht,!also!das!Commitment!gegenüber!dem!Product!Owner,!von!der!Innensicht,!in!der!sich!das!Team!einen!Plan!macht,!um!dieses!Commitment!umzusetzen.!Die!tägliche!Planung!wird!im!Daily!Scrum!synchronisiert!und!–!ähnlich!einer!Einsatzplanung!–!wird!der!Tag!des!Entwicklerteams!geplant.!

3.3.1! Relative'Schätzungen'mit'Story'Points'

Schätzen!und!Planen!wird!einfacher,!wenn!man!nicht!gleich!in!Zeiteinheiten!wie!Personentagen!denkt,!sondern!zunächst!eine!Basisgröße!für!eine!User!Story!wählt!und!dann!die!Größe!der!anderen!Stories!in!Relation!dazu!setzt.!Für!diese!abstrakte!Einheit!hat!sich!die!Bezeichnung!„Story!Point“!eingebürgert.!Diese!Einheit!liefert!zunächst!zwar!noch!keine!Information!darüber,!wie!viele!Personentage!ein!Punkt!bedeutet,!aber!nach!dem!Sprint!zählt!man!die!Story!Points!der!fertigen!User!Stories!zusammen!und!die!Umrechnung!in!Personentage!auf!Basis!der!verbrauchten!Zeit!ist!eine!einfache!Dreisatzrechnung.!

Die!Schätzung!läuft!z.B.!wie!folgt!ab:!Für!die!Story!A,!die!mir!bereits!vertraut!ist,!setze!ich!2!Story!Points!an.!Den!Aufwand!für!Story!B!schätze!ich!halb!so!groß!wie!A,!also!einen!Story!Point,!die!Story!C!halte!ich!für!viermal!so!groß!wie!Story!A!und!gebe!ihr!8!Story!Points.!Noch!besser!wird!das!Ergebnis!oft,!wenn!jeder!Schätzer!jede!User!Story!mit!zwei!anderen!ihm!bereits!vertrauten!Stories!größenmäßig!in!Beziehung!setzt,!eine!Methode,!die!man!auch!als!„Triangulation“!bezeichnet.!

Story'Points'als'Stabilitätsfaktor'für'die'Aufwandschätzung'

Das!Arbeiten!mit!Story!Points!hat!mehrere!Vorteile.!Zum!einen!geht!die!von!konkreten!Aufwänden!losgelöste!Schätzung!schneller,!Komplexität!und!Größenverhältnisse!der!Features!im!Projekt!werden!sichtbar.!Da!Story!Points!nur!eine!Vergleichsgröße!darstellen,!bleiben!sie!stabil,!selbst!wenn!erste!Aufwandschätzungen!korrigiert!werden!müssen.!Gleiche!große!Stories!bekommen!auch!später!die!gleiche!Zahl!von!Story!Points.!!



Und!das!Ganze!hat!noch!eine!psychologische!Komponente:!Mit!Story!Points!als!relative!Größe!ohne!konkrete!Maßeinheit!überlistet!man!das!eigene!Unterbewusstsein,!das!dazu!tendiert,!mit!Sätzen!wie!„Das!darf!doch!nicht!so!viel!kosten!“!die!Schätzung!zu!manipulieren.!

Bestimmung'der'Velocity'

Nach!einem!Sprint!addiert!man!die!Story!Points!der!fertigen!und!abgenommenen!Stories,!und!berechnet!so!die!erreichte!Velocity!eines!Sprint.!Die!durchschnittliche!Velocity!pro!Sprint!gibt!dem!Product!Owner!die!Möglichkeit,!die!Restdauer!des!Releases!zu!schätzen!und!einen!Releasetermin!zu!planen.!

Nach!Abschluss!des!ersten!Sprints!kann!man!erste!Prognosen!darüber!aufstellen,!wie!viele!Story!Points!das!Team!in!einem!Sprint!abarbeiten!kann.!Allerdings!schwanken!bei!neuen!Teams!die!Werte!für!die!Velocity!oft!stark,!ein!gutes!Team!erreicht!erfahrungsgemäß!nach!drei!bis!fünf!Sprints!eine!stabile!Velocity,!die!zuverlässige!Hochrechnungen!für!das!Gesamtprojekt!bzw.!das!Release!möglich!macht.!

Was!kann!man!tun,!wenn!der!Product!Owner!am!Anfang!eine!Schätzung!braucht?!Wenn!das!gleiche!Team!schon!vorher!zusammengearbeitet!hat,!helfen!auch!hier!Story!Points,!man!kann!die!Kalibrierung!der!Stories!aus!dem!vorigen!Projekt!auf!die!neuen!Stories!anwenden.!!

Story'Points'gelten'nur'für'das'eigene'Team'

Aber!Vorsicht:!Die!Natur!der!Schätzung!macht!Story!Point!nur!innerhalb!eines!Teams!zu!einem!brauchbaren!Prognosemittel,!sie!sind!nur!bedingt!zwischen!Teams!übertragbar:!

!! Jedes!Team!hat!andere!Stories!als!Basis!der!Kalibrierung!gewählt.!

!! Auch!bei!gleichen!Stories!ist!nicht!gewährleistet,!dass!in!einem!anderen!Team!dieselbe!Verteilung!von!Fähigkeiten!und!Erfahrungen!gegeben!ist,!sodass!das!andere!Team!andere!Aufgaben!schwer!bzw.!leicht!finden!wird.!

!! Ein!Versuch,!über!Vergleich!der!Velocities!zweier!Teams!einen!Leistungsvergleich!durchzuführen,!macht!sofort!die!„Währung“!Story!Point!unbrauchbar:!Nichts!ist!leichter!für!ein!Team!als!einfach!höhere!Schätzungen!abzugeben!–!die!Währung!„Story!Point“!erleidet!eine!Hyperinflation!und!ist!wertlos.!

Um!Story!Points!in!einem!größeren!Projekt!mit!mehreren!Teams!vergleichbar!zu!machen!und!für!die!Releaseplanung!nutzen!zu!können,!ist!es!notwendig!die!Größenskala!zwischen!den!Teams!z.B.!durch!ReferenzGStories!zu!kalibrieren.!!

3.3.2! Die'Kunst'des'Schätzens'

Eine!wichtige!Voraussetzung,!um!bei!der!Aufwandschätzung!verschiedener!User!Stories!gut!voranzukommen,!liegt!in!der!Wahl!geeigneter!Größen.!Wer!in!zu!kleinen!Einheiten!denkt,!verzettelt!sich!unweigerlich!in!Diskussionen!im!Kampf!mit!völlig!unnötigen!!Genauigkeiten.!Kann!ich!eine!1GPunktGStory!von!einer!2GPunktGStory!unterscheiden?!In!aller!Regel!ja,!denn!die!zweite!braucht!schließlich!den!doppelten!Aufwand.!Kann!ich!



auch!eine!17GPunktGStory!von!einer!18GPunktGStory!unterscheiden?!Nein,!mit!Sicherheit!nicht.!Denn!hier!würde!es!um!eine!Präzisierung!gehen,!die!dem!Verständnis!von!„Schätzung“!widerspricht.!Plausibel!sind!Skalen,!die!intuitiv!sind,!bei!denen!mit!zunehmenden!Werten!auch!die!Abstände!wachsen!oder!die!den!Teilnehmern!aus!Erfahrung!vertraut!sind,!wie!zum!Beispiel:!

!! Zweierpotenzen:!1,!2,!4,!8,!16!oder!

!! Verschwommen!wirkende!Skalen!wie!1,!2,!3,!5,!8,!13,!die!die!ersten!Zahlenwerte!aus!der!FibonacciGReihe!entlehnt!hat!oder!

!! TGShirt!Größen:!XS,!S,!M,!L,!XL,!XXL.!

Für!User!Stories,!die!keinen!oder!nur!marginalen!Aufwand!erfordern,!ist!es!auch!einmal!möglich.!die!Größen!0!oder!½!zu!verwenden4.!Wichtig!ist!es,!dass!die!einmal!gewählte!Skala!während!der!gesamten!Projektlaufzeit!möglichst!stabil!bleibt,!denn!nur!so!kann!sich!die!gewünschte!Planungserfahrung!in!einer!stabilen!Velocity!niederschlagen.!

Wenn!das!Team!im!Lauf!der!Zeit!schneller!wird,!wird!man!das!allein!an!der!wachsenden!Velocity!sehen,!es!besteht!kein!Grund,!die!Kalibrierung!zu!ändern.!

3.3.3! Planning'Poker'

Diese!Schätzmethode!baut!auf!der!BreitbandGDelphiGMethode!auf5,!bei!der!mehrere!Experten!herangezogen!werden,!die!sich!untereinander!abstimmen.!Als!Messgröße!dienen!Story!Points!oder!auch!(wenn!die!Tasks!im!Sprint!Planning!geschätzt!werden)!Zeiteinheiten!wie!Entwicklerstunden!oder!Gtage.!Wichtige!Anforderung!für!die!Skala!ist,!wie!oben!beschrieben,!dass!die!Abstände!nach!oben!größer!werden.!!

Im!Schätzmeeting!diskutieren!Product!Owner!und!Team!zunächst!jede!einzelne!User!Story,!so!dass!ein!gemeinsames!Verständnis!dieser!Aufgabe!entsteht.!Der!Product!Owner!erläutert!die!Anforderungen,!die!hinter!den!Product!BacklogGEinträgen!stehen,!und!das!Team!stellt!Fragen!dazu.!Wenn!das!Team!die!Story!verstanden!hat,!macht!jedes!Teammitglied!seine!(verdeckte)!Schätzung,!dann!decken!alle!gemeinsam!ihre!Wertungen!auf.!!

Die!Resultate,!insbesondere!die!Ausreißer,!werden!diskutiert,!bis!das!Team!eine!gemeinsame!Meinung!erzielt!hat.!!

Wir!empfehlen:!

!! insbesondere!über!die!größten!und!kleinsten!Werte!zu!diskutieren:!Dahinter!verbergen!sich!oft!Lösungsansätze!oder!umgekehrt!das!Wissen!um!Probleme,!die!den!anderen!Teammitgliedern!entgangen!sind!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!4 ein Beispiel für 0 ist eine externe Zulieferung, die zwar keinen eigenen Aufwand erfordert, aber der Vollständigkeit halber integriert werden muss. Die Notwendigkeit zur Verwendung von ½ ist ein Hinweis darauf, dass das Team nicht die optimale Basis gewählt hat und eine falsche Granularität verwendet 5 http://de.wikipedia.org/wiki/Delphi-Methode#Breitband-Delphi-Methode



!! Echter!„Poker“!–!die!Karten!zuvor!verdeckt!hinlegen!und!wirklich!gleichzeitig!aufdecken,!keine!Beeinflussung!der!anderen!Teammitglieder!

!! Vertreten!und!Argumentieren!meiner!Schätzung!–!nicht!einfach!um!des!lieben!Friedens!wegen!nachgeben!(„gut,!dann!nehme!ich!auch!eine!2“)!

Planning!Poker!hat!eine!Menge!wertvoller!Seiteneffekte,!die!die!Vorteile!dieser!Methode!noch!erhöhen.!Planning!Poker!

!! gewährleistet,!dass!das!Team!auf!bisherigen!Erfahrungen!aufbaut,!

!! unterstützt,!dass!das!Team!sich!besser!kennenlernt!und!zusammenwächst,!

!! bezieht!ausnahmslos!alle!Teammitglieder!ein,!

!! lässt!das!Expertenwissen!und!unterschiedliche!Sichtweisen!wirksam!werden,!

!! verhindert!Manipulation!durch!dominante!Teammitglieder,!!

!! fördert!die!Kommunikation!des!Teams!mit!dem!Product!Owner,!!

!! eliminiert!Unterschiede!in!Risikosicht!und!Zeitgefühl,!

!! führt!in!aller!Regel!einen!Konsens!herbei,!

!! bringt!gerade!in!Situationen!mit!unvollständigem!Wissen!sehr!gute!Ergebnisse.!

Beim!Planning!Poker!gilt!exemplarisch,!was!wir!bereits!über!die!Planung!allgemein!gesagt!haben:!Durch!das!gemeinsame!Schätzen!lernen!die!Teammitglieder!eine!Menge!über!den!Gegenstand!und!über!die!Herangehensweise!der!andern.!Es!hat!dadurch!einen!eigenen!Wert,!der!über!die!gewonnenen!Zahlen!hinausgeht.!

Affinity'Estimation'

Affinity!Estimation!ist!ein!ähnliches!Verfahren!wie!Bucket!Estimation,!aber!es!kommt!am!Anfang!ohne!einen!Kalibrierungsschritt!aus.!Zuerst!werden!die!Stories!nach!ihrer!Größe!sortiert!ausgelegt,!mit!ähnlichen!Vorgaben!wie!bei!der!Bucket!Estimation.!Das!Ziel!ist,!dass!die!Stories!in!einer!Reihe!liegen!mit!der!größten!Story!an!einem!Ende!und!der!kleinsten!am!anderen!Ende!der!Reihe.!Erst!danach!werden!die!Pokerkarten!mit!den!Schätzgrößen!parallel!dazu!ausgelegt.!Die!Stories!sind!demnach!schon!der!Größe!nach!geordnet,!wenn!ihnen!jetzt!eine!Skala!zugeordnet!wird.!!

Der!Skalierungsschritt!liegt!also!am!Ende!des!Vorgangs.!Das!vermindert!das!Risiko,!dass!man!eine!zu!grobe!oder!zu!feine!Skala!gewählt!hat!und!mit!ungünstigen!Zahlen!leben!muss.!

! ! Scrum!im!Unternehmen!


4!Scrum'im'Unternehmen'

Die!Ziele!eines!Unternehmens!laufen!nicht!immer!konform!mit!den!Zielen!eines!agilen!Projektes.!In!einem!agilen!Projekt!haben!die!Beteiligten!das!Ziel,!mit!minimalem!Aufwand!einen!maximalen!Wert!und!das!bestmögliche!Produkt!zu!liefern.!Dem!stehen!häufig!Unternehmensziele!entgegen,!die!z.B.!ein!detailliertes!Finanzcontrolling,!Dokumentationspflichten!oder!ein!standardisiertes!InfrastrukturG!und!Personalmanagement!erfordern.!Bei!der!Anwendung!agiler!Praktiken!gibt!es!daher!häufig!Konflikte!mit!bestehenden!UnternehmensGRegeln.!!

Als!Teammitglieder!aber!auch!als!agile!Manager!oder!Product!Owner!können!wir!diese!Konflikte!oft!nicht!abstellen!–!sie!bleiben!uns!als!organisatorische!Hindernisse!erhalten!–!aber!wir!können!sie!verstehen!und!damit!!

!! Argumente!für!den!Einzelfall!entwickeln,!um!Entscheidungen!zu!beeinflussen,!

!! ein!Verständnis!zu!entwickeln,!um!die!dahinter!stehende!Logik!zu!begreifen!und!ggfls.!zu!nutzen.!

4.1! Organisatorische'Gründe'für'Ineffektivität'

In!jedem!Unternehmen!gibt!es!Regeln!und!Richtlinien,!die!auf!effiziente!Prozesse,!hohe!Qualität!und!Controlling!abzielen!und!damit!letztendlich!gewährleisten!sollen,!dass!mit!den!vorhandenen!Ressourcen!höchstmögliche!Produktivität!erreicht!wird.!Allerdings!haben!diese!Normen!nicht!immer!die!gewünschte!Wirkung.!Oft!blockieren!Richtlinien!den!idealen!Entwicklungsprozess!durch!Wartezeiten!oder!Prozesse!werden!mit!vielfältigen!ControllingGMechanismen!überfrachtet.!

Für!uns!in!der!Softwareentwicklung!ist!dieses!Phänomen!in!zweierlei!Hinsicht!relevant:!Zum!einen!wird!der!kreative!Entwicklungsprozess!von!manchen!Vorgaben!eingeschränkt.!Zum!anderen!werden!die!zu!entwickelnden!Systeme!immer!komplexer!und!die!Rahmenbedingungen,!die!man!uns!einräumt,!immer!unrealistischer.!!

Das'Problem'der'Komplexität'?'Less'is'more'

Die!Komplexität!eines!Gesamtsystems!steigt!mit!jedem!neuen!Element!exponentiell.!Viele!Softwaresysteme!werden!zu!komplex,!da!Anforderungen!und!Features!nicht!priorisiert!sind!und!der!Kundennutzen!nicht!hinterfragt!wurde.!Übergabeformalien!oder!falsches!Erwartungsmanagement!suggerieren,!der!Umfang!der!Systeme!sei!nicht!verhandelbar.!Warnungen!von!Entwicklungsspezialisten!werden!als!Renitenz!oder!Bequemlichkeit!interpretiert,!und!das!Management!entscheidet!sich!unbeeindruckt!von!allen!Einwänden!für!eine!komplexe!„Goldrandlösung“.!Das!Ergebnis!kennen!wir,!unfertige!Systeme,!die!mit!vielen!Fehlern!ausgeliefert!werden!und!nur!mit!hohem!Aufwand!wartbar!sind.!!!

Scrum!im!Unternehmen!


Wunschdenken'–'Unrealistische'Ziele'

Nicht!nur!in!der!Softwareentwicklung!herrscht!ein!allgegenwärtiges!Wunschdenken:!Man!wünscht!sich!das!System!mit!all!den!vielen!Features,!die!auf!der!langen!Wunschliste!stehen.!Nachdem!dann!eine!erste!Planung!und!Schätzung!zeigt,!dass!nicht!alles!in!der!gewünschten!Zeit!realisierbar!ist,!wird!trotzdem!versucht,!so!viel!wie!möglich!zu!bekommen,!auf!Kosten!der!Qualität.!

Dasselbe!gilt!für!den!Entwicklungsprozess!selbst:!Wir!prüfen!nicht!die!Nützlichkeit!eines!neuen!Werkzeugs,!produzieren!keine!Prototypen,!haben!keine!systematische!Methode,!aus!unserer!Arbeit!Erkenntnisse!zu!gewinnen.!Wir!wollen,!dass!es!so!klappt,!also!wird!es!das!auch!–!oder?!

Technische'Schulden'

Ein!Resultat!von!unrealistischen!Projektzielen!sind!Technische!Schulden.!Viele!Unternehmen!tolerieren!unfertigen!Code,!drängen!Entwickler!zu!unrealistischen!Zeitplänen!und!sparen!am!Refactoring,!um!die!Illusion!aufrecht!zu!erhalten,!das!Ziel!sei!doch!noch!zu!erreichen.!Die!Auswirkungen!unzureichender!Qualität!wie!steigende!Wartungskosten!und!unzufriedene!Kunden!werden!meist!zu!spät!wahrgenommen.!!

In!Unternehmen,!in!denen!eine!fehlende!Priorisierung!und!unrealistische!Ziele!einen!guten!Entwicklungsprozess!verhindern,!ist!es!oft!die!reine!Notwehr!der!Entwickler,!die!zu!technischen!Schulden!führt.!Schlechte!Software!ausliefern!heißt!technologische!Schulden!machen.!Und!wie!andere!Schulden!muss!man!auch!die!zurückzahlen.!

Abbildung!4.1:!Die!Auswirkungen!von!Technischen!Schulden!

Zielvereinbarungen'und'Performance'Kennzahlen'

Viele!Performance!Kennzahlen!in!Unternehmen!messen!die!individuelle!Auslastung!der!Mitarbeiter!und!verhindern!damit!eine!gute!Teamleistung.!Tom!DeMarco!und!Timothy!


Integration testScenario test

TesMng"on"different"levels

UnitTest

UnitTest

UnitTest

UnitTest

Non functional TestsPerformance tests

Acceptance testsUsability testsAutomated

Manual

Special Tools


UnitUnitUnit

UnitUnitUnitUnit

Technical"debts"h"what"is"the"value"of"tesMng?

Unit UnitUnitUnit

RemainingEffort

Time

Techn

ical

Debts

Sprint 1

Sprint 2

Sprint 3



Lister6!nennen!dieses!Phänomen!„teamicide“,!wenn!durch!individuelle!Leistungsbewertung!die!Stimmung!und!TeamGMoral!untergraben!wird.!!

Dinge!können!sich!rapide!in!die!falsche!Richtung!entwickeln,!wenn!man!versucht,!die!Leistung!eines!„Wissensarbeiters“!zu!messen.!Ein!Belohnungssystem!auf!der!Basis!von!„Lines!of!Code“!verführt!z.B.!dazu!viele!Zeilen!fehlerhaften!Code!zu!schreiben.!Falls!das!Unternehmen!dann!beschließt,!eine!Strafe!für!die!Anzahl!von!Fehlern!im!Code!einzuführen!wird!jeder!versuchen,!die!Fehler!einfach!zu!verstecken.!!

Wir!empfehlen!als!entscheidende!Bewertungsgröße!die!TeamGProduktivität!zu!nutzen.!Wir!interessieren!uns!vornehmlich!für!die!Kundenzufriedenheit,!Teamzufriedenheit!und!die!Wertschöpfung.!Das!diese!zugegebenermaßen!nicht!einfach!zu!messen!sind,!kann!man!auf!abgeleitete!Kennzahlen!zurückgreifen:!TeamGKennzahlen!wie!stabile!Velocity,!TestGAbdeckung!und!Fehlerhäufigkeit!sollten!regelmäßig!gemessen!und!mit!dem!Team!analysiert!werden!(der!wichtige!Aspekt!ist:!mit!dem!Team).!Jedes!Team!wird!versuchen,!auf!Basis!seiner!Bewertung!kontinuierlich!besser!zu!werden.!Wir!glauben!nicht,!dass!finanzielle!Belohnungssysteme!die!Produktivität!eines!Teams!weiter!verbessern!können.!

Auslastung'und'Effektivität'

Lange!Zeit!galt!es!als!oberste!Maxime,!dass!eine!optimale!Einsatzplanung!darin!besteht,!alle!Mitarbeiter!möglichst!zu!jedem!Zeitpunkt!hundertprozentig!auszulasten.!Das!war!nicht!auf!die!Softwareentwicklung!beschränkt!und!es!ist!den!meisten!von!uns!in!Fleisch!und!Blut!übergegangen,!dass!es!nicht!Schlimmeres!gibt!als!eine!nicht!ausgelastete!Ressource!–!und!darunter!zählte!man!wie!selbstverständlich!auch!die!Mitarbeiter.!

Doch!Anfang!der!achtziger!Jahre!reifte!in!der!Umgebung!industrieller!Fertigungsanlagen!die!Erkenntnis,!dass!eine!hundert!Prozent!Auslastung!einige!unerwünschte!Nebeneffekte!hat.!Ausschlaggebend,!so!die!neue!Erkenntnis,!sei!die!Optimierung!des!Systems!insgesamt!und!nicht!die!lokale!Optimierung!in!den!einzelnen!Arbeitsschritten.!Unter!normalen!Bedingungen,!so!das!Ergebnis!umfassender!Testläufe,!ist!das!Optimum!erreicht,!wenn!die!einzelnen!Stationen!zu!zirka!achtzig!Prozent!ausgelastet!sind.!Das!ist!eine!ziemlich!überraschende!Zahl,!aber!sie!ist!mit!vielen!Praxiserfahrungen!abgesichert!und!hat!eine!solide!mathematische!Entsprechung!in!der!Warteschlangentheorie.!

Eliyahu!M.!Goldratt!hat!das!in!seiner!„Theory!of!Constraints“7!(TOC)!bewusst!gemacht!und!in!einem!unterhaltsamen!Buch!„Das!Ziel“!anschaulich!verpackt.!Vor!allem!gelte!es,!so!seine!Botschaft,!Engpässe!zu!erkennen!und!an!diesen!den!Durchfluss!aufrechtzuerhalten.!

Dieser!Ansatz!lässt!sich!teilweise!in!die!SoftwareentwicklungsGPerspektive!übertragen.!Der!erste!Teil!ist!die!Betrachtung!der!Auslastung:!es!dürfen!nicht!immer!alle!Teammitglieder!komplett!oder!–!auch!das!ergibt!sich!aus!der!HundertGProzentGForderung!schnell!–!sogar!zu!mehr!als!hundert!Prozent!ausgelastet!sein!!Die!Gründe!liegen!eigentlich!auf!der!Hand:!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!6 Tom DeMaro und Timothy Lister, Peopleware: Productive Projects and Teams, 1999 7 Eliyahu Goldratt: Das Ziel. Campus Verlag 2001



!! Wenn!eine!vollständige!Auslastung!vorliegt,!kann!das!Team!keinerlei!neue!Anforderungen!oder!überraschende!Informationen!mehr!verkraften.!

!! Mit!Scrum!kann!ein!erfahrenes!Team!sehr!schnell!erkennen,!wann!eine!Aufgabe!in!einem!Sprint!auf!dem!kritischen!Pfad!ist.!Das!Team!braucht!dann!genügend!freie!Kapazität,!um!das!Augenmerk!auf!diese!Aufgabe!richten!zu!können!und!zu!verhindern,!dass!diese!Aufgabe!von!anderen!Aufgaben!blockiert!wird.!!

!! Bei!einer!vollständigen!Auslastung!ist!keine!kreative!Arbeit!mehr!möglich.!Man!kann!–!für!eine!begrenzte!Zeit!–!funktionieren,!aber!das!ist!keine!Zielsetzung,!die!der!nachhaltigen!Weiterentwicklung!der!Mitarbeiter!oder!der!Firmenziele!dient.!

Es!gibt!aber!einen!wichtigen!Unterschied!zwischen!der!Theory!of!Constraints!und!dem!Funktionieren!eines!ScrumGTeams:!Bei!der!TOCGFertigung!ist!es!von!zentraler!Bedeutung,!dass!die!„kritische!Ressource“!optimal!ausgelastet!ist.!Oft!ist!das!eine!besonders!teure!Maschine!oder!ein!aufwändiger!Prozessschritt.!Übertragen!auf!ein!Softwareteam!wäre!das,!dass!der!Mitarbeiter,!dessen!spezielles!KnowGhow!im!Projekt!gerade!am!meisten!!gefragt!ist!–!optimal!arbeiten!kann.!Das!ist!aber!sowohl!unnötig!als!auch!gefährlich:!

!! Kopfmonopole!gefährden!den!Projekterfolg:!die!jeweiligen!unentbehrlichen!Mitarbeiter!können!im!Zweifelsfall!nicht!einmal!mehr!in!Urlaub!fahren.!Wir!kennen!ein!Team,!das!eine!grobe!Formulierung!dafür!gefunden!hat,!sie!reden!vom!TruckGFaktor:!Wie!viele!Teammitglieder!müssen!mindestens!vom!Truck!überfahren!werden,!bis!das!Projekt!blockiert!ist?!

!! Kopfmonopole!neigen!dazu,!sich!zu!verfestigen.!Da!der!Kollege!die!wichtigsten!und!anspruchsvollsten!Aufgaben!übernimmt,!bekommt!er!auch!die!beste!Weiterbildung.!

!! Kopfmonopole!führen!dazu,!dass!im!Extremfall!fast!das!ganze!Team!wartet!und!nicht!arbeiten!kann.!

Wir!bauen!statt!dessen!darauf,!dass!das!kritische!KnowGHow!besser!im!Team!verteilt!wird.!Deshalb!sind!Techniken!wie!Pair!Programming!auch!ein!zentrales!Mittel!zur!Verbesserung!der!Gesamtperformanz!des!Teams!und!ein!Mittel!zur!Wissensverbreitung!und!Risikominimierung!in!der!Softwareentwicklung.!

4.2! Agile'Werte'im'Unternehmen'verankern'

„Lean!Thinking“!ist!wie!schon!beschrieben!ein!Konzept,!das!auf!die!Schaffung!von!Werten!ohne!Verschwendung!abzielt.!Es!breitet!sich!immer!mehr!in!Unternehmen!aus.!Mary!und!Tom!Poppendieck8!!haben!in!„Lean!Software!Development“!gute!Handlungsmuster!geliefert!wie!man!Software!Entwicklung!schlanker!machen!kann.!Ihre!wichtigsten!Prinzipien!sind:!vermeide!Verschwendung,!ermögliche!Lernen,!liefere!so!schnell!wie!möglich!und!stärke!das!Team.!!

Je!besser!„Lean!Thinking“!bereits!in!der!Unternehmenskultur!verankert!ist,!desto!leichter!ist!es!für!agile!Softwareentwickler,!Anerkennung!und!Respekt!zu!ernten.!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!8 Mary and Tom Poppendieck, Lean Software Development, An agile Toolkit, 2003



Vertraut!das!Unternehmen!hingegen!auf!eine!relativ!akribische!PlanungsG!und!Controllingkultur,!muss!man!das!agile!Gedankengut!erst!aktiv!im!Unternehmen!verbreiten!was!nicht!immer!einfach!ist.!

Die!Rolle!eines!Evangelisten!liegt!nicht!jedem,!aber!die!ersten!agilen!Erfolge!in!einem!Unternehmen!verbreiten!sich!oft!von!selbst.!Wer!mehr!tun!möchte!kann!in!Gesprächen!mit!Kolleginnen!und!Kollegen!oder!bei!firmeninternen!Veranstaltungen!versuchen,!gezielt!um!Verständnis!für!agile!Werte!zu!werben.!Beim!Management!wirkt!es!oft!Wunder,!wenn!ein!Product!Owner!über!seine!positiven!Erfahrungen!berichtet.!Ziel!solcher!„Öffentlichkeitsarbeit“!kann!nicht!nur!sein,!die!Akzeptanz!für!die!Arbeit!eines!agilen!Entwicklerteams!zu!fördern.!Es!ist!durchaus!sinnvoll,!sich!dafür!einzusetzen,!dass!auch!Geschäftsbereiche!außerhalb!der!IT!von!den!Vorteilen!der!Agilität!profitiert.!!

4.3! Agiles'Controlling'und'Reporting'

Scrum!hat!gegenüber!dem!traditionellen!Projektmanagement!den!entscheidenden!Vorteil,!dass!es!ohne!aufwändige!Controlling!und!Dokumentationsinstrumente!jederzeit!eine!hohe!Transparenz!über!den!Projektfortschritt!liefert.!Die!ständige!Rückkopplung!nach!jedem!Sprint!mit!dem!Product!Owner!und!anderen!Stakeholdern!ist!klassischen!Statusberichten!und!Ampelgrafiken!weit!überlegen.!Am!Ende!des!Sprints!weiß!jeder!was!fertig!ist!oder!nicht,!Software!zum!Anfassen,!fertig!entwickelt,!getestet!und!demonstriert.!!

Abbildung!4.2:!Menschen!passen!ihr!Verhalten!an!die!Bewertung!an!

Ein!noch!intensiveres!ControllingGInstrument!ist!das!ständige!Feedback!im!Scrum!Team:!Tägliche!„Daily!Scrum“!mit!Kurzberichten!und!Bewertung!der!restlichen!Arbeit!im!Sprint!Burndown,!Messung!der!TeamGVelocity!–!bei!all!diesen!Feedback!Loops!ist!es!kaum!möglich,!dass!jemand!unbemerkt!wochenlang!einem!Irrweg!folgt!und!dies!nicht!korrigiert!wird.!

Als!geeignete!Methode,!um!iterative!Entwicklungsprojekte!auch!längerfristig!planen!und!verfolgen!zu!können!hat!sich!die!Projektverfolgung!in!einem!Release!Burndown!(wie!in!Bild!03G08!gezeigt)!bewährt.!Dadurch!wird!einprägsam!visualisiert,!welche!Fortschritte!erzielt!wurden,!wo!es!Verzögerungen!gab!und!auch!wie!sich!der!Scope!entwickelt!hat.!Zudem!ist!dieses!Dokument!in!der!Sprache!des!Kunden!verfasst,!die!Ergebnisse!sind!für!Controlling!und!Management!verständlich!und!nachvollziehbar.!

Lines of Code Unrefaktorierter Code

Rechtzeitige Lieferung

Schlampige Software



In!vielen!Scrum!Teams!hat!es!sich!außerdem!eingebürgert,!am!Ende!jedes!Sprints!einen!Sprint!Report!zu!erstellen,!um!messbare!Ergebnisse!an!die!Stakeholder!und!das!Management!zu!kommunizieren.!Ein!Sprint!Report!kann!z.B.!folgende!Punkte!enthalten:!

!! Sprint:!Datum!von!Start!und!Ende!!

!! Teammitglieder,!Arbeitstage!–!geplant!und!erbracht!!

!! fertiggestellte!und!unfertige!User!Stories!!

!! ungeplante!Arbeit!(Defects,!ProductionGIssues,...)!

!! Story!Points!geplant!und!geliefert!(d.h.!die!Velocity)!!

!! aufgetretene!und!beseitigte!Hindernisse!!

!! Testabdeckung!durch!UnitG!und!Akzeptanztests!

Einen!gewissen!Lerneffekt!im!Projektumfeld!kann!man!manchmal!mit!der!Veröffentlichung!bzw.!dem!sichtbaren!Aufhängen!des!Impediment!Logs!erreichen.!Wenn!hier!z.B.!dokumentiert!wird,!wie!oft!Mitarbeiter!unerwartet!für!andere!Projekte!abgezogen!werden,!kann!das!den!Impuls!geben,!auch!an!anderen!Orten!die!Planung!zu!verbessern.!

4.4! Das'Projektgedächtnis'organisieren'

Wie!lässt!sich!sicherstellen,!dass!längerfristige!Entwicklungen!in!einem!Projekt!und!die!Erfahrungen!aus!einem!ScrumGProjekt!für!neue!und!alte!TeamGMitglieder!nachvollziehbar!bleiben?!Als!ein!passendes!Medium!haben!sich!ProjektGWikis!erwiesen,!die!sehr!gut!der!Philosophie!von!agil!entsprechen:!Man!kann!sehr!klein!anfangen!und!muss!nicht!alle!Eventualitäten!voraussehen.!Im!Verlauf!des!Projekts!wächst!das!Medium!mit!seinen!Aufgaben.!Zudem!verträgt!es!nicht!nur!Text,!sondern!nimmt!auch!andere!Formate!wie!Fotoprotokolle!auf.!!

Für!die!Organisation!und!Struktur!des!Wikis!gibt!es!viele!Möglichkeiten.!Man!sollte!darauf!achten,!dass!die!Team!unmittelbar!Nutzen!daraus!ziehen!und!das!Wiki!nicht!ausschließlich!etwa!der!Dokumentation!für!die!Nachwelt!dient.!!

Folgende!Inhalte!haben!sich!in!ProjektGWikis!als!nützlich!erwiesen:!

!! Was!wurde!gemacht?!

!! Welche!Entscheidungen!wurden!warum!getroffen?!

!! Was!muss!der!Entwickler!wissen?!

!! Was!muss!der!Nutzer!wissen?!

!! Was!muss!der!Betrieb/der!User!Helpdesk!wissen?!

Weitere!Punkte!können!sein:!

!! Zusätzliche!Dokumentation,!z.B.!DeploymentGInformationen,!Nachweise!für!Compliance!!



!! Mitarbeiter,!Zugänge,!Abgänge,!Urlaubszeiten!

!! Log!wichtiger!ProjektGInformationen,!z.B.!Entscheidungen!oder!Ereignisse!

!! Dokumentation!der!Hindernisse!und!der!herbeigeführten!Ergebnisse!z.B.!im!ImpedimentGBacklog!!

4.5! Buchhaltung'und'Abrechnung'

Für!die!!ProjektGBuchhaltung!in!einem!ScrumGProjekt!gibt!es!sowohl!unternehmensinterne!als!auch!externe!Möglichkeiten!der!LeistungsG!und!Kostenverrechnung.!!

Unternehmensintern!steht!beispielsweise!ein!Budget!für!eine!SoftwareGEntwicklung!zur!Verfügung.!Idealerweise!ist!der!Product!Owner!Eigentümer!bzw.!Verwalter!dieses!Budgets!und!bezahlt!daraus!die!Kosten!des!Scrum!Teams.!Er!kann!vor!jedem!Sprint!entscheiden,!welche!Stories!das!Team!liefern!soll.!Bei!einem!Team!mit!stabiler!Velocity!kann!man!die!Kosten!eines!Features!anhand!der!Story!Points!einfach!ermitteln.!Anhand!der!durchschnittlichen!Kosten!eines!Sprint!kann!man!ausserdem!hochrechnen,!wann!das!Budget!verbraucht!sein!wird.!Diese!Information!braucht!der!Product!Owner,!um!die!Erwartungen!der!Stakeholder!entsprechend!managen!zu!können.!

Eine!erprobte!Abrechnungsform!für!ScrumGProjekte!mit!externen!Kunden!ist!die!Vereinbarung,!dass!der!Kunde!pauschal!die!Kosten!für!das!Team!je!Sprint!bezahlt,!wobei!im!Vorfeld!vereinbart!wird,!was!am!Ende!des!Sprints!geliefert!werden!soll.!Dafür!erhält!der!Kunde!das!SprintGResultat,!d.h.!neue!Produktinkremente,!bestehend!auf!den!fertiggestellten!User!Stories.!Dieses!Vorgehen!ist!transparent!und!nachvollziehbar!und!erspart!komplizierte!Vertragsvereinbarungen.!Andererseits!muss!der!Lieferant!keinen!Aufschlag!für!unternehmerisches!Risiko!wie!bei!einem!Festpreis!kalkulieren.!

Viele!Projekte!verlangen!eine!Arbeitszeiterfassung!bezogen!auf!einzelne!Tasks.!Dies!ist!aus!Sicht!von!Scrum!nicht!nur!Verschwendung,!sondern!wirkt!sich!in!der!Regel!auch!negativ!auf!die!Effektivität!des!Teams!aus,!das!ja!gemeinsam!die!insgesamt!beste!Lösung!finden!soll.!!

Gerade!in!projektbasierten!Dienstleistungsorganisationen!ist!eine!Granularität!auf!Ebene!Sprint!und!Team,!also!das!„Buchen!auf!einen!Sprint“!(noch)!nicht!möglich.!Eine!gute!Lösung!für!eine!Zeitaufzeichnung!in!solchen!Fällen!wäre!zum!Beispiel!die!Anzahl!der!geleisteten!Stunden!(des!gesamten!Teams)!pro!UserGStory!aufzuzeichnen,!also!„auf!eine!Story!zu!buchen“.!

!



Index'

Affinity!Estimation!........................................!36!Agiles!Manifest!...............................................!3!Auftraggeber!................................................!11!Auslastung!...............................................!38,!39!Backlog!Grooming!........................................!23!BreitbandGDelphiGMethode!..........................!35!Chief!Product!Owner!....................................!10!Command!and!Control!.................................!14!commitment!..............................................!8,!12!Controlling!....................................................!37!Daily!Scrum!.....................................................!8!DEEP!.............................................................!21!Definition!of!Done!..........................................!9!done!...............................................................!9!emergent!......................................................!16!FaceGtoGfaceGKommunikation!.......................!11!Feedback!........................................................!5!Feedback!Loops!............................................!41!Festpreis!.......................................................!43!Fibonacci!......................................................!35!Fotoprotokolle!..............................................!42!funktionale!Spikes!........................................!21!grooming!......................................................!23!Hinderniss!.......................................................!7!Impediment!....................................................!7!Impediment!Backlog!......................................!7!Industrialisierung!............................................!4!Komplexität!..................................................!37!Kopfmonopol!................................................!40!Lean!Thinking!...............................................!40!Mediator!......................................................!13!Moderator!....................................................!13!nachhaltigen!Weiterentwicklung!.................!40!Öffentlichkeitsarbeit!....................................!41!Pair!Programming!.........................................!40!Planungsebenen!...........................................!32!Product!Backlog!............................................!15!Product!Owner!..........................................!6,!10!Product!Owner!Team!...................................!10!Produkt!Backlog!Eisberg!...............................!16!

ProduktGInkrement!.......................................!12!Projektleiter!.................................................!14!ProjektGWikis!................................................!42!ready!..............................................................!9!Release!Burn!Down!Chart!............................!19!ReleaseGDaten!..............................................!10!Respekt!.........................................................!40!Ressourcenauslastung!..................................!39!Restaufwände!..............................................!18!Return!On!Invest!..........................................!11!Risikominimierung!........................................!40!ROI!................................!Siehe!Return!On!Invest!Rollenkonflikt!...............................................!14!Scrum!Master!.................................................!6!ScrumGTeam!...................................................!7!selbstorganisiertes!Team!...............................!7!Servant!Leader!........................................!13,!14!SMART!..........................................................!18!spikes!............................................................!21!Sprint!Backlog!............................................!7,!17!Sprint!Burn!Down!Chart!...............................!18!Sprint!Review!.................................................!8!Sprintplanung!.................................................!8!SprintGZiel!.......................................................!8!Stakeholder!...............................................!8,!10!Systemadministrator!....................................!12!Team!...............................................................!7!Teamcoach!...................................................!13!Teamrollen!...................................................!12!technische!Schulden!.....................................!38!technische!Spikes!.........................................!21!Tester!...........................................................!12!Theory!of!Constraints!...................................!39!TruckGFaktor!......................!Siehe!Kopfmonopol!Tunnelblick!...................................................!24!Umsetzungsteam!...........................................!7!unternehmerisches!Risiko!............................!43!User!Story!.....................................................!16!Wissensverbreitung!......................................!40!Wunschdenken!.............................................!38!

!

!

PDF-Version https://improuv.com/content/scrum-kompakt

improuv GmbH Giesinger Bahnhofplatz 981539 München

https://improuv.com [email protected] +49 89 500 352 10

Train - improuv€¦ · Inhalt! ©!improuv!GmbH!|!!! ! 1! Inhalt' Inhalt!.....!1!

Documents

Transcript of Train - improuv€¦ · Inhalt! ©!improuv!GmbH!|!!! ! 1! Inhalt' Inhalt!.....!1!