Seite 1 von 17

Scrum – auf dem Bierdeckel erklärt Begriffe, Konzepte, Grundverständnis

März 2019, Version 1.2

Seite 2 von 17

Vorwort DiesesPaperführtinScrumein.EserläutertdiegrundlegendenBegriffeundKonzepteunderläutert,wiediesezusammenhängen.DieScrum-Mechanik istnurdieeineSeitederMedaille.DiedahinterstehendenWerteundPrinzipiensindmindestensgenausowichtig.DaherfindetsichnachderScrum-EinführungeineBeschreibungdesagilenManifestes,dasdieagilenPrinzipiendefiniert.DanachfindetsicheineÜbersichtüberdieScrum-Rollen,-Artefakteund–Meetings,diezumNachschlagengeeignetist.

DiesesPaperhilftdemScrum-Neuling,sicheinenerstenÜberblicküberdieFunktionsweisevonScrumzuverschaffen.DiesesGrundverständnisdientalsOrientierungshilfefürdieweitereVertiefunginScrum,diedurch Scrum-Einführungsbücher 1 oder Schulungen2 erfolgen kann. Auf keinen Fall sind Sie nach derLektüredieseskurzenArtikelsinderLage,Scrumeinzuführen.

Inhalt

SCRUM–DREIPERSPEKTIVEN 3PRODUKTPERSPEKTIVE 4ENTWICKLUNGSPERSPEKTIVE 6VERBESSERUNGSPERSPEKTIVE 7

DIESCRUMWERTE 8COMMITMENT 8OFFENTHEIT 8FOKUS 8MUT 8RESPEKT 9

DASAGILEMANIFEST 9WERTEPAARE 9PRINZIPIEN 10

ÜBERBLICKÜBERDIESCRUM-ROLLEN,-MEETINGSUND-ARTEFAKTE 11ROLLE:SCRUMMASTER 11ROLLE:PRODUCTOWNER 12ROLLE:ENTWICKLUNGSTEAM 13MEETING:DAILYSCRUM 14MEETING:SPRINTPLANNING 14MEETING:SPRINT-REVIEW 15MEETING:SPRINT-RETROSPEKTIVE 15ARTEFAKT:PRODUCTBACKLOG 16ARTEFAKT:SPRINTBACKLOG 16ARTEFAKT:AUSLIEFERBARESPRODUKTINKREMENT 17

1z.B.StefanRoock,HenningWolf:„Scrum-verstehenunderfolgreicheinsetzen“2z.B.http://www.it-agile.de/schulungen

Seite 3 von 17

Scrum – Drei Perspektiven MankannScrumineinemSatzbeschreiben:

Scrumbedeutet:AutonomeTeamsmitBusiness-Fokus,

dieihrenProzessinVerantwortungnehmenundkontinuierlichverbessern.

In diesem Satz werden drei Perspektiven sichtbar,ausdenenmanScrumbetrachtenkann:

1. Die Produktperspektive (Business-Fokus)beleuchtet, wie Produkte definiert undverbessertwerden.

2. Die Entwicklungsperspektive (autonomeEntwicklungsteams) beleuchtet,wie TeamsProdukteentwickeln.

3. Die Verbesserungsperspektive (Prozess inVerantwortung nehmen) beleuchtet, wieZusammenarbeit und Prozesse verbessertwerden.

Diese drei Perspektiven werden in das Scrum-Frameworkintegriert,dassoeinfachist,dassesaufeinenBierdeckelpasst(sieheAbbildungrechts)3.

WirbeschreibendiedreidargestelltenPerspektivenindenfolgendenAbschnittenausführlicher.

3 Den dargestellten Scrum-Bierdeckel gibt es im it-agile-Shop:http://www.itagileshop.de

Seite 4 von 17

Produktperspektive DieProduktperspektivebeginntmitderProduct-Owner-Rolle. Der Product Owner verantwortet denProdukterfolg, indem er den Produktnutzen durch diePriorisierung der Produkt-Features optimiert. DerProduct Owner darf Entscheidungen über das Produkttreffen. Man kann sich den Product Owner auch alsUnternehmerimUnternehmenvorstellen.

FürdenProductOwnergiltdasHighlander-Prinzip:„Eskannnureinengeben.“DieRollekanninScrumnichtvonmehrerenPersonengeteiltwahrgenommenwerdenundschongarnichtdurcheinKomitee.ManmöchteinScrum,dass der Product Owner mit einer Stimme gegenüberdem Team und den Stakeholdern spricht undEntscheidungenschnellfällenkann.

DerProductOwnerverfolgteineProduktvision.PassendzurProduktvisionpflegtderProductOwnereinProductBacklog, in dem die Produkteigenschaften beschriebensind, die für den Produkterfolg notwendig erscheinen.Das Product Backlog wird durch den Product OwnerpriorisiertunddurchdasEntwicklungsteamgeschätzt.

Scrum legt nicht fest, wie genau die Einträge desProduct Backlogs gestaltet sind. Viele Teamsmachengute Erfahrungen mit User Stories: ExemplarischeBenutzungsszenarien aus Sicht eines Benutzers. UserStories haben eine andere Qualität als klassischeAnforderungen.BeiUserStoriesliegtderFokusdarauf,ein gemeinsamesVerständnisbei allenBeteiligten zuerzeugen und nicht darauf, dass die Beschreibungvollständig,widerspruchsfreiundkorrektist.

Die Entwicklung erfolgt in Iterationen, die in ScrumSprintsheißen.SprintshabeneineimmergleicheLängevonmax.4Wochen.WasimSprintentwickeltwird,wirdim Sprint Planning festgelegt. Hier werdenhochpriorisierte Einträge aus dem Product Backlogausgewählt, von denen das Entwicklungsteam meint,dasssiesieimSprintumsetzenkönnen.DasErgebnisistein auslieferbares Produktinkrement. Ob dasProduktinkrement tatsächlich an Kunden ausgeliefertwird, entscheidet der Product Owner. Die imProduktinkrement implementierten Features müssenaber auf jeden Fall produktionsreif sein (mind.entwickeltundqualitätsgesichert).

Seite 5 von 17

Das Entwicklungsteam demonstriert am Ende jedesSprints das Produktinkrement im Sprint Review denStakeholdern4,damitdieseFeedbackzumProduktgebenkönnen. Das Feedback wird vom Product Ownerentgegengenommenundnach seinemErmessen indasProductBacklogintegriert.

GuteFragen,umnützlichesFeedbackzuerhalten,sind:

• „Was hindert uns daran, das vorliegendeProduktinkrementproduktivzubenutzen?“

• „Wie kann das vorliegende Produktinkrementnochwertvollergestaltetwerden?“

4StakeholderistinScrumjeder,derInteresseamProduktoderEinflussauf die Entwicklung hat: Kunden, Anwender, Sponsoren, Manager,Betriebsratetc.

Seite 6 von 17

Entwicklungsperspektive DasEntwicklungsteamentwickeltausgehendvomSprintBacklogeinauslieferbaresProduktinkrement.Esbestehtaus3-9Teammitgliedern,diealleFähigkeitenvereinen,die notwendig sind, um das Sprint Backlog in dasProduktinkrement zu überführen. Entwickler sind jenach Kontext Programmierer, UX-Experten, Designer,Handbuch-Autoren,TesteroderandereExperten.

Das Entwicklungsteam organisiert sich selbst. Es gibtweder eine formelle Hierarchie noch herausgehobeneRollenoderPositionen.

DasEntwicklungsteambestimmtimSprintPlanning,wievielArbeitesindenSprintaufnimmt.EswendetdasPull-Prinzip an (es „zieht“ Arbeit in den Sprint). Für dieausgewähltenEinträgeausdemProductBacklogerstelltdasEntwicklungsteameinenPlanfürdieUmsetzungimSprint. Die ausgewählten Einträge aus dem ProductBacklogzusammenmitdemUmsetzungsplanbildendasSprintBacklog.

Das Entwicklungsteam macht so eine Vorhersage(Forecast)darüber,wasesimSprintschaffenkann.DieseVorhersage soll die Qualität einer Wettervorhersagehaben. In der Regel sollte das Entwicklungsteam dasliefern, was es eingeplant hat. Es sollte aber niemandübermäßig überrascht sein, wenn das hin und wiedernichtklappt.

Während des Sprints treffen sich die Teammitgliederwerktäglich zum Daily Scrum, um sich über denArbeitsfortschrittunddienächstenAufgaben imSprintabzustimmen.DazukommendieTeammitglieder jedenWerktag zur gleichen Uhrzeit am gleichen Ort fürmaximal 15Minuten zusammenund beantworten dreiFragen:

1. Was wurde seit dem letzten Daily Scrumerledigt,wasunsdemSprintzielnähergebrachthat?

2. WelcheHindernissesehenwiraufdemWegzumSprintziel?

3. WasplanenwirbiszumnächstenDailyScrumzuerledigen,wasunsdemSprintzielnäherbringt?

Der Product Owner ist ein optionaler Teilnehmer amDailyScrum.

Seite 7 von 17

Verbesserungsperspektive Der ScrumMaster ist ein Coach für alle Beteiligten. Ersorgtdafür,dassProductOwner,dasEntwicklungsteamund Stakeholder verstehen,wie Scrum funktioniert. ErhilftIhnen,Scrumeffektivanzuwenden.GegenüberdemEntwicklungsteamschafftereinenRahmen,indemsichdasTeamselbstorganisierenkannundhältdemTeamimmer wieder den Spiegel vor. Der Scrum Masterkümmert sich außerdem darum, dass Impediments(Hindernisse) identifiziert und beseitigt werden. ErmoderiertinderRegeldieScrum-Meetings.

Die kontinuierliche Verbesserung desEntwicklungsprozesses ist bei Scrum in zweiMeetingsverankert. Zum einen nehmen Verbesserungen ihrenAusgangimDailyScrum,wennHindernisseidentifiziertwerden.HindernissesindinScrumalles,wasdieArbeitan aktuellenAufgabenblockiert oder verlangsamt.DerScrum Master kümmert sich um die Beseitigung derHindernisse. Das bedeutet nur selten, dass er dasHindernisalleineausderWeltschafft.ErwirddazuinderRegel mit weiteren Parteien im Unternehmeninteragieren müssen (z.B. um finanzielle Mittel fürschnellereRechnerzubeschaffen).

Zum anderen findet am Ende des Sprints die SprintRetrospektive statt. Hier reflektiert dasEntwicklungsteam zusammenmit dem Product Ownerdarüber,wasimletztenSprintgutundwaswenigergutgelaufen ist. Auf dieser Basis definieren sieVerbesserungsmaßnahmen, die sie im nächsten Sprintumsetzen. Mindestens eine Maßnahme wird Teil desSprint Backlogs des nächsten Sprints. Die SprintRetrospektivewirddurchdenScrumMastermoderiert.

Seite 8 von 17

Die Scrum Werte Scrum ist nur ein Rahmen, der individuell von Teamsausgefüllt werden muss. Die Werte helfen und gebenOrientierung,welchederselbstgewähltenLösungengutzu Scrum passen und welche eher nicht. Die WertedefinierendamitquasidasScrum-Mindset.

Commitment CommitmentinsDeutschezuübersetzenistehersperrig.Dem am nächsten käme wohl der Begriff (Selbst-)Verpflichtung. Commitment ist für Scrum-Teamswichtig, vor allem im Sinne einer Selbstverpflichtungjedes Teammitglieds, weil man Scrum eben nichtverordnenkann.DasTeammusssowohldieAufgabealsauch die Zusammenarbeit bewusst annehmen. Nur sokönnen die Aufgaben erfolgreich ausgeführt werden.Commitment bedeutet dabei auch, dass die MitgliedermitganzemHerzendabeisindunddasseseinemnichtegal ist, ob die Aufgabe gelingt. Alle im Scrum-Teammüssenwirklichwollen, dass die Aufgabe gelingt, undsichdafüreinsetzen.

Offenheit Offenheit bedeutet, dass alle im Team sowohl gehörtwerden als auch alle Informationen haben, um besteErgebnissezuerzielen.NursolässtsicheinevernünftigePlanungundeinrealistischerForecasterreichen.Dasistbesonders dann wichtig, wenn die Arbeit des Teamsnicht direkt sichtbar ist (z. B. Softwareentwicklung).Natürlich geht es bei Offenheit auch darum, zupersönlichen Schwächen oder Fehlern zu stehen unddiese nicht zu vertuschen oder zu verbergen, damitgemeinsamdarausgelerntwerdenkannundeinUmgangmitdemProblemfürdieZukunftgefundenwird.Dafürist Offenheit nötig, weil sie die Grundlage für einegemeinsameSichtermöglicht.

Fokus DieKraft,dieimWertFokusliegt,leuchtetdenmeistenintuitivsofortein.DasmachtfokussiertesArbeitenabernochlangenichteinfachundselbstverständlich.DieIdeevon Jeff Sutherland, dass Scrum-Teams die doppelteMengeanArbeitinderHälftederZeiterledigenistohneFokus niemals möglich. Zudem gehört dazu, dass alleScrum-Teammitglieder voll dabei sind und nicht nochandereAufgabenwahrnehmen.

Mut Es braucht Mut für Offenheit, es braucht Mut fürVeränderungen und es braucht Mut, Problemeanzusprechen.DiesenMutbenötigensowohldieTeamsalsauchdieFührungskräfte,diesichmitScrumaufeinanderes Arbeiten einlassen. Damit wird auch deutlich,dass Mut ein zentraler Wert ist, der das Leben deranderenWerteerstermöglicht.

Seite 9 von 17

Respekt Respekt ist eine wesentliche Voraussetzung fürOffenheit.NurmitRespektkannmangemeinsamdaranarbeiten,besserzuwerden.Dafür isteswichtig,nichtsund niemanden zu verurteilen. Viele Unternehmenhaben eine ausgeprägte Blaming-Kultur, suchen alsoständigdenSchuldigen.Das ist aberkeineerfolgreicheStrategieund löstnichtdieProbleme! IndiesemSinneträgt Scrum mit dem Wert Respekt dazu bei,Organisationen (wieder) erfolgreich zu machen. DasLeben dieses Wertes schafft in der Organisation eineUmgebung,diemehrMöglichkeiteneröffnet.

Das agile Manifest Wertepaare FüragileEntwicklunggibtesmitdemAgilenManifest5einLeitbilddafür,wasAgilitätbedeutet.

DiesesLeitbildbeginntmitvierWertaussagen:

• IndividuenundInteraktionensindwichtigeralsProzesseundTools

• LaufendeSoftwareistwichtigeralsausführlicheDokumentation

• ZusammenarbeitmitdemKundenistwichtigeralsVertragsverhandlungen

• Reagieren auf Veränderungen istwichtiger alsPlanbefolgung

Obwohl wir die Werte auf der rechten Seite wichtigfinden,schätzenwirdieWerteaufderlinkenSeitehöherein.

In klassischen Kontexten generieren die Dinge auf derrechtenSeitesubjektivwahrgenommeneSicherheit.WersichandieProzessehältunddievorgeschriebenenToolseinsetzt, wer jede seiner Tätigkeiten haarkleindokumentiert, wer alle Eventualitäten in Verträgenberücksichtigtundwer sichandenPlanhält, kannbeiProblemennachweisen,dassernicht schuld ist.Leidergenerierenwir auf dieseWeise in komplexenMärktenkeinen Geschäftswert. In dynamischen MärktenbrauchenwirdieFlexibilität,dieunsdieDingeaufderlinkenSeitegeben.

Dieser Gegensatz erklärt,warumdie Einführung agilerVerfahren in der Praxis häufig so schwierig ist. AlleBeteiligten müssen ein Stück dieser „Sicherheit durchStatik“ loslassen, um auf den Kunden und denGeschäftswertfokussierenzukönnen.

5http://agilemanifesto.org

Seite 10 von 17

Prinzipien Ergänzt werden die vier Wertaussagen durch zwölfPrinzipien,diekonkretisieren,wiedieWertesichaufdietäglicheArbeitauswirken:

1. Unsere höchste Priorität ist es, den Kundendurch frühe und kontinuierliche AuslieferungwertvollerSoftware6zufriedenzustellen.

2. Heiße Anforderungsänderungen selbst spät inder Entwicklung willkommen. Agile Prozessenutzen Veränderungen zumWettbewerbsvorteildesKunden.

3. Liefere funktionierende Software regelmäßiginnerhalb weniger Wochen oder Monate undbevorzugedabeidiekürzereZeitspanne.

4. FachexpertenundEntwicklermüssenwährenddesProjektestäglichzusammenarbeiten.

5. Errichte Projekte rund um motivierteIndividuen. Gib ihnen das Umfeld und dieUnterstützung, die sie benötigen und vertrauedarauf,dasssiedieAufgabeerledigen.

6. Die effizienteste und effektivste Methode,Informationen an und innerhalb einesEntwicklungsteams zu übermitteln, ist imGesprächvonAngesichtzuAngesicht.

7. Funktionierende Software ist das wichtigsteFortschrittsmaß.

8. AgileProzessefördernnachhaltigeEntwicklung.Die Auftraggeber, Entwickler und Benutzersollten ein gleichmäßiges Tempo aufunbegrenzteZeithaltenkönnen.

9. StändigesAugenmerk auf technischeExzellenzundgutesDesignfördertAgilität.

10. Einfachheit-dieKunst,dieMengenichtgetanerArbeitzumaximieren-istessenziell.

11. Die besten Architekturen, Anforderungen undEntwürfe entstehen durch selbstorganisierteTeams.

12. In regelmäßigen Abständen reflektiert dasTeam,wieeseffektiverwerdenkannundpasstseinVerhaltenentsprechendan.

6 Außerhalb der IT kann der Begriff Software problemlos durchProduktoderServiceersetztwerden.

Seite 11 von 17

Überblick über die Scrum-Rollen, -Meetings und -Artefakte

DieserAbschnittgibtprägnanteÜbersichtenundChecklisten für die Rollen, Meetings undArtefaktevonScrum.DiesesolltenaufkeinenFalldogmatischverwendetwerden.EsgibtnichtdieeinerichtigeForm,dieMeetingsdurchzuführen,die Rollen auszuleben oder die Artefakte zugestalten. Dieser Abschnitt kann aber alsKurzreferenz helfen sowie als Startpunkt, umüberhaupteinmalmitirgendetwasanzufangen.

Rolle: Scrum Master DieMeetingsmacheninScruminderSummeca.10%derZeitaus.RechnenwirfürdieVor-undNachbereitung noch einmal dieselbe Zeit,verbleibtdocheinerheblicherAnteilArbeitszeit,indenenderScrumMastersichaufandereWeisenützlichmacht.WelcheAufgabenScrumMasterin der Praxis übernehmen, hängt vomUnternehmen,vomProjektundvonderReifedesTeamsab.ImFolgendenfindetsicheineListemitBeispielen aus der Praxis. Die fett gesetztenPunktesinddieAufgaben,diederScrumMasteraufjedenFallwahrnehmenmuss.

Teamebene

1. Gemeinsam mit dem TeamRetrospektiven-Maßnahmenumsetzen

2. Die Entwickler unterstützen, ein besserestechnischesVerständniszuerwerben,dabeiggf. an Entwicklermeetings teilnehmen undagile Entwicklungspraktiken einführen(testgetriebeneEntwicklung,kontinuierlicheIntegration,PairProgramming)

3. GeradefürneueScrum-Teams:demTeambeimUmgangmitVeränderungenhelfen,diebeimUmstiegaufScrumanstehen

4. Materialnachschub fürs Taskboardorganisieren

5. Einzelgespräche mit Entwicklern führen;generell ein Ohr am Team haben, ummitzubekommen,waslosist

6. Impediments aufnehmen und bei derBehebung unterstützen: Diese könnenkonkretauseinzelnenEntwicklungsaufgabenresultieren, Teamprobleme sein,KommunikationsproblemeimTeam,mitdemProduct Owner oder zu Stakeholdern, sichaber auch aufOrganisationsebenebefinden.(WasdarfdasTeam,werstörtdasTeam?)

7. Für Festlegung von Teamspielregelnsorgenunddiesegutsichtbarmachen

8. Teammitglieder an die vereinbartenSpielregelnerinnern

9. Einzelgespräche mit Teamfokus: Wasbrauchstdu im/vomTeam?Wiegehtesdirgerade?Wiezufriedenbistdu?Feedbackandich, Feedback von dir?Wie sehe ich deineRolleimTeamunddeinenBeitragfürsTeam?Wo stehst du dem Team im Weg? Wokönntest du dich mehr einbringen?(Empfehlung: Einzelgespräche alle zwei bisdrei Wochen mit jedem TeammitgliedinklusiveProductOwnerführen.)

10. Aha-Momente oder Leidensdruckerkennen als Initialpunkt für sofortigeVeränderung (nicht immer nur Input fürRetrospektiven,oftauchdirektumsetzbar)

11. Netzwerk durchforsten für Ideen, wie manProbleme/Herausforderungen des Teamslösenkönnte(Optionenschaffen)

12. BeurteilungderSituationmitScrum-Master-Kollegen, Coaches oder Netzwerkdiskutieren, um wach zu bleiben und nichtauf die eigene Perspektive beschränkt zubleiben

13. InformativenWorkspace gestalten bzw. dasTeamanregen,ihnzugestaltensowieaktuellundhilfreichzuhalten

14. Organisatorische Aufgaben wie das BuchenvonMeetingräumenetc.(abernichtso,dassdie Teammitglieder das nicht mehr selbstkönnen)

15. Social Events für das Team-Buildingorganisieren (das kann auch das BestärkenvonKollegensein,diedanndieOrganisationübernehmen)

16. Auf Missstände hinweisen, selbst wenndieseerstmal fürdasTeamkeingroßesProblemzuseinscheinen(Beispiel:Sprintswerdennichtgeschafft,wasdasTeamzwarnichtsodramatischfindet,derScrumMasteroderdieStakeholderaberschon.)

Seite 12 von 17

17. Konfliktemoderieren18. Beteiligung an Diskussionen,

insbesondere um zu helfen, mehrOptionen zu schaffen und auf Datenaufmerksam zu machen sowieBeobachtungenwiederzugeben (auchmalaufGuteshinweisen,alsoDinge,dieschongutlaufen)

19. Sessions zum ThemaEigenverantwortlichkeitorganisieren

20. DemTeamhelfen,Akzeptanzkriteriendirektin testbare Form zu bringen und dannentsprechendautomatisiertzutesten

21. In Konfliktsituationen Einzelgespräche mitTeammitgliedernführen

22. DasTeamvorunerwünschtenEinflüssenvon außen schützen, also z.B.Teammitgliedern den Rücken stärken, dievon ihrem Chef für nicht vereinbartezusätzliche Aufgaben abgezogen werdensollen

Teamübergreifende Organisationsebene

23. Unterstützung bei der Organisation vonteamübergreifendem Wissenstransferzwischen Entwicklern, Testern etc.,beispielsweise in Communities of Practice(CoP)

24. AustauschmitanderenScrumMastern (z.B.in einer Scrum-Master-CoP, aber auch überCommunity-Events), um überHerausforderungen und Verbesserungen zusprechen und um neue Ideen fürVerbesserungsmaßnahmenzubekommen

25. NeueScrumMasterausbilden26. TeilnahmeanMeetingsundGesprächenmit

ZuliefererndesTeamsoderEmpfängernvonTeamergebnissen gemeinsam mitTeammitgliedern und dem Product Owner,damit das Team optimal in dieGesamtprozesseeingebundenistundimmeralle nötigen Informationen hat (undweitergibt)

27. Scrum erklären: Rollen, Meetings,Artefakte und Werte erklären für dasTeam,aberauchfürweiterePersonenimUnternehmenoderbeiKunden

28. WennesschonhalbwegsläuftmitScrum,anOrganisationsmeetings teilnehmen, die dasTeambetreffen(könnten),umAnregungenfür mehr oder konsequenteres Scrum zugeben, die Teambedürfnisse zukommunizieren und um direktereKommunikationmitdemTeamherzustellen

29. TeamübergreifendenAustauschanregen(aufProduct-Owner-undTeamebene)

30. Mit Rat und Tat Fragen zu Scrumbeantworten für das Team undAußenstehende

31. Mit Managern, Projektleitern,Teamleitern etc. über Rechte undPflichten der Teams sprechen unddarüber,wiedieTeamsgestärktwerdenkönnen

32. Scrum/agilderPersonalabteilungerklären33. Zusammenspiel/Abstimmung zwischen

Teamsverbessern34. Manager dabei unterstützen, das Team für

schwierigepersonelleSituationenLösungenfinden zu lassen, anstatt selbst Lösungenvorzugeben

35. DieinternenScrumMasterunterstützenundcoachen

36. Änderungen der Team-Zusammensetzungmoderieren

37. DasControllingmitderneuenScrum-WeltinVerbindungbringen

38. Die unternehmensinterne Vernetzung derScrum Master und „Agilen“ über Spartenhinausbegleiten

Anforderungsebene und Product Owner unterstützen

39. Bei Story-Schnitt und Backlog-Organisation den Product Ownerunterstützen

40. Den Product Owner beim Stakeholder-Managementunterstützen

41. Mit dem Product Owner und mit denEntwicklern das Schreiben von UserStoriesüben

42. Den Product Owner dabei unterstützen,die Anforderungsflut strukturierter zubewältigen

43. Die Prozessfindung beimPortfoliomanagement der Product OwnerundStakeholderbegleiten

Rolle: Product Owner Die Aufgaben des Product Owners variierenabhängig von Unternehmen und Projekt. Diefolgende Liste enthält Beispiele von Product-Owner-Aufgaben aus der Praxis. Die fettgesetzten Punkte sind die Aufgaben, die derProductOwneraufjedenFallwahrnehmenmuss.

Produkteigenschaften

1. Produktvisionerstellen

Seite 13 von 17

2. Produktvision an Stakeholder undEntwicklunsteamkommunizieren

3. Schreiben von Product Backlog Items(allein, mit Stakeholdern, mit demEntwicklungsteam)

4. Akzeptanzkriterien für Product BacklogItemsformulieren(inderRegelzusammenmitdemEntwickungsteam)

5. Ordnen/Priorisieren des ProductBacklogs(inkl.Entscheidung,wasentwickeltwirdundwasnicht)

6. Die bereits entwickeltenProduktinkrementekennen

7. Mit den bereits entwickeltenProduktinkrementen„herumspielen“

8. DieWertschöpfungdesProduktsdefinieren9. DieWertschöpfungdesProduktskennen,

messenundoptimieren10. Produktbezogene Feedbackschleifen

installierenundverkürzen

Zusammenarbeit mit dem Team

11. RefinementdesProductBacklogs (in derRegelzusammenmitdemTeam)

12. Zu große Product Backlog Itemsaufsplitten(inderRegelzusammenmitdemEntwicklungsteam), sodass sie in Sprintspassen

13. Eine Sprint-Ziel-Skizze in das SprintPlanningmitbringen

14. Hoch priorisierte, gut ausgearbeiteteProduct-Backlog-Einträge in das SprintPlanningmitbringen

15. MitarbeitimSprintPlanning16. Beantwortung fachlicher Fragen des

Entwicklungsteams im Sprint PlanningundwährenddesSprints

17. TeilnahmeanDailyScrums18. Teilnahme an und Mitarbeit in Sprint-

Retrospektiven19. Dem Entwicklungsteam helfen, seinen

Prozesszuverbessern20. DefinitionderDefinitionofReadyzusammen

mitdemEntwicklungsteam21. Definition der Definition of Done

zusammenmitdemEntwicklungsteam22. FeedbackzuimplementiertenFeaturesan

dasTeamimSprintoderimSprint-Review23. Dem Entwicklungsteam eigene

Unzufriedenheiten deutlich machen underklären, Mitarbeit bei der Suche nachLösungen

24. Dem Entwicklungsteam die relevantenGeschäftszahlen/KPIstransparentmachen

25. Dem Entwicklungsteam verdeutlichen, wiedas Produkt auf dem Markt bzw. bei denKundenankommt

Kunden/Anwender

26. Kundenbedürfnisse verstehen (mitKunden/Anwendernsprechen)

27. DenMarktverstehen28. Ausgewählte Kunden/Anwender in die

Sprint-Reviewsintegrieren29. Aufsetzen und Durchführen geeigneter

Erfolgsmetriken (z.B. KundenzufriedenheitüberdenNetPromoterScoremessen)

30. Risikomanagement über dieOrdnung/Priorisierung des ProductBacklogs

31. Annahmen überKunden/Anwender/Märkte testen (z.B.miteinemMinimumViableProduct)

Management sonstiger Stakeholder

32. Dafür sorgen, dass die richtigenStakeholderzumSprint-Reviewkommen

33. Erstellung und Aktualisierung desReleaseplans

34. AktualisierungdesReleaseBurnupCharts35. Kommunikation von Releaseplan und

ReleaseBurnupChartandieStakeholder36. StakeholderüberneueProdukteigenschaften

informieren37. Budgetkontrolle

Rolle: Entwicklungsteam Die Aufgaben des Entwicklungsteams variierenabhängigvonUnternehmenundProjekt.WaszudenAufgabendesEntwicklungsteamsgehörtundwas nicht dazu gehört,wird zumGroßteil überdieDefinitionofReadyunddieDefinitionofDoneformuliert. Die folgende Liste enthält Beispielevon Aufgaben des Entwicklungsteams aus derPraxis. Die fett gesetzten Punkte sind dieAufgaben, die das Entwicklungsteam auf jedenFallinScrumwahrnehmenmuss.

Arbeitsorganisation

1. Umsetzungsplan im Sprint Planningerstellen

2. Organisation der Teamarbeit im DailyScrum

3. PairProgrammingmitTeammitgliedern4. EinarbeitungneuerTeammitglieder

Seite 14 von 17

Technisch

5. Produktinkremente programmieren,testenunddokumentieren

6. Automatisierte Tests (Unit Tests,Integrations-, Last-, Akzeptanztests)erstellenundkontinuierlichdurchführen

7. System- und Softwarearchitekturerstellen

8. SoftwaretechnischerEntwurf9. AuswahlgeeigneterTechnologienfürdie

Umsetzung10. Betrieb und Support der entwickelten

Software

Bezogen auf Stakeholder

11. Usability-Testsdurchführen12. UserAcceptanceTestsdurchführen13. Umgebung für Continuous Integration

aufsetzenundamLaufenhalten14. Produktinkremente im Sprint-Review

demonstrieren15. UserExperiencegestalten16. Bugsbeseitigen

Unterstützung des Product Owners

17. SchätzungdesProductBacklogs18. Den Product Owner bei der Konzeption

unterstützen.19. Zusammen mit dem Product Owner

Product Backlog Items erstellen und imRefinementverfeinern

Verbesserung

20. Sich selbst bezüglich Technologien,Vorgehen und Fachwissenweiterentwickeln

21. Zusammen mit dem Product Owner dieDefinitionofReadyformulieren

22. Zusammen mit dem Product Owner dieDefinitionofDoneformulieren

Meeting: Daily Scrum n Ergebnis: Einsatzplanung für das Team für

denTagn Dauer:max.15Minuten(jedenWerktagzur

selbenUhrzeitamselbenOrt)n Teilnehmer: Entwicklungsteam und Scrum

Master;ProductOwneroptional;Stakeholderoptional (Stakeholder dürfen zuhören, abernichtsprechen)

n Vorgehen (dieTeammitgliederbeantwortendreiFragen):

• Washabeichgesternerledigt,wasmeinemEntwicklungsteamgeholfenhat,dasSprint-Zielzuerreichen?

• Habe ich Hindernisse gesehen, die michoderdasEntwicklungsteamdaranhindern,dasSprint-Zielzuerreichen?

• Waswerdeichheuteerledigen,ummeinemEntwicklungsteam zu helfen, das Sprint-Zielzuerreichen?

n Empfehlungen:• Das Daily Scrum findet vor einemphysikalischenTaskboardstatt.

• Die ersten beiden der obigen FragenwerdeneinzelnvondenTeammitgliedernbearbeitet.WenndiesebeidenFragenvonjedemTeammitgliedbeantwortetwurden,wirddiedritteFragegemeinsamimTeambeantwortet.

• Hindernisse,diedieWeiterarbeitaneinemSprint Backlog Item oder einem Taskblockieren, werdenmit roten Haftnotizendirekt auf den zugehörigen User Storiesbzw.Taskskenntlichgemacht.

• Andere Hindernisse werden in der NähedesTaskboardsvisualisiert.

Meeting: Sprint Planning n Ergebnisse: selektierte Einträge aus dem

Product Backlog, Plan für die Umsetzung,Sprint-Ziel

n Dauer: maximal zwei Stunden pro Sprint-Woche (also vier Stunden für einenzweiwöchigenSprint)

n Teilnehmer: Product Owner, ScrumMaster,Entwicklungsteam, bei Bedarf eingeladeneFachexperten für spezifische anstehendeFachfragen

n Vorgehen:• DerScrumMaster fragtdasTeam,welcheDingeinnerhalbderZeitspannepassieren,dieunsereKapazitätbeeinflussen?

• DerProductOwnerstelltseineIdeefüreinSprint-ZielvorsowiediehochpriorisiertenProductBacklogItems.

• Der Scrum Master fragt dasEntwicklungsteam, ob das erste ProductBacklog Item in den Sprint passt.Beantwortet das Entwicklungsteam dieFrage positiv, fragt der ScrumMaster, obdaszweiteProductBacklogItemzusätzlichindenSprintpasst.DiesesVerfahrenwirdso langewiederholt,bisdasTeamZweifelhat,obesnochmehrschaffenkann.

Seite 15 von 17

• JetztwirddasSprint-Zielüberarbeitetundfinalisiert. Der Product Owner schätzt ab,obderSprinteinenpositivenROI(Returnon Investment) hat, wenn die gewähltenBacklog Items umgesetztwerden können.Wenn dies nicht der Fall ist, geht dasScrum-TeamzurückzumerstenSchritt.

• Dann wird der sogenannte Task-Breakdown durch das Entwicklungsteameingeleitet.DazuwerdenKleingruppenvonjeweilszweibisdreiEntwicklerngebildet.Jede Kleingruppe wählt einen Teil derBacklogItemsausunderstelltdieTasksfürdieUmsetzung.

• Die erstelltenTaskswerdenanschließendim Plenum vorgestellt, und es wirdFeedback eingesammelt. Gegebenenfallswird eine zweite RundeKleingruppenarbeitangeschlossen.

• Es wird auf Basis der erstellten Tasksgeprüft,obdieausgewähltenBacklogItemstatsächlich im Sprint umgesetzt werdenkönnen.

• DerProductOwnerwirdüberdasErgebnisder Abschätzung informiert.GegebenenfallswirdeinBacklog Itemausdem Sprint Backlog entfernt oder eineweiteres hinzugefügt. Wenn notwendig,wirddasSprint-Zielangepasst.

n Empfehlungen:• DerBeamerbleibtaus.DerProductOwnerbringtdieProductBacklogItemsaufPapiermit.DieTaskswerdenebenfallsaufPapiererstellt.

• Der Product Owner bleibt während desTask-Breakdown imRaum. (Häufig tretenbei dieser Tätigkeit weitere fachlicheRückfragenauf.)

• Für die Tasks gilt die Regel, dass siemaximal einen Personentag an Aufwandgroß sein dürfen. Tasks müssen alsoentsprechendkleingestaltetsein.

Meeting: Sprint-Review n Ergebnisse: Klarheit darüber, was am

ProduktmithoherPrioritätnochzutun ist;Änderungen am Product Backlog; ggf.FortschreibungdesReleaseplans

n Dauer: ca. eine Stunde pro Sprint-Woche(also zwei Stunden für einen zweiwöchigenSprint)

n Teilnehmer: Product Owner, Scrum Master(Moderation), Entwicklungsteam,

Stakeholder (insbesondere Kunden undAnwender)

n Vorgehen:• Demonstration des Produktinkrementsdurch das Entwicklungsteam. DieDemonstration erfolgt auf einer vorhervereinbarten Test- undIntegrationsumgebungundnichtaufeinemEntwicklerrechner. Es darf nur gezeigtwerden,wasgemäßderDefinitionofDonekompletterledigtist.

• Gegebenenfalls Akzeptanz der Featuresdurch den Product Owner (wenn nichtbereitsimSprinterfolgt)

• GegebenenfallsAktualisierungdesReleaseBurnupCharts(sieheunten)

• FeststellungdurchdenProductOwner,obbzw. inwieweit das Sprint-Ziel erreichtwurde

• Sammeln von Feedback zum Produkt;Festhalten des Feedbacks durch denProductOwner

• Feststellen, welches Feedback besondersdringlich ist. Anpassung des ProductBacklogs bezüglich dieses dringlichenFeedbacksdurchdenProductOwner

• Gegebenenfalls Anpassung desReleaseplans

n Empfehlungen:• Der Product Owner sorgt dafür, dass dierichtigen Stakeholder beim Sprint-Reviewanwesendsind.

• Der Product Owner bettet den aktuellenSprintindasGesamtvorhabenein.

• DieDemonstrationdesProduktinkrementsbasiertaufdemSprint-ZielunderzählteineGeschichte, die es den Stakeholdernerleichtert, das Gezeigte in einengeeignetenKontextzusetzen.

• DerScrumMastersorgtdurchModerationdafür, dass die Stakeholder nützlichesFeedbackzumProduktgeben.

• Bei vielen Stakeholdern im Sprint-Reviewsorgt der Scrum Master durch geeigneteTechniken der GroßgruppenmoderationfürdieeffektiveDurchführungdesSprint-Reviews.

Meeting: Sprint-Retrospektive n Ergebnisse: Verbesserungsmaßnahmen, die

das Scrum-Team im nächsten Sprintumsetzenwill

Seite 16 von 17

n Dauer:ca.eineStundeproSprintwoche(alsozweiStundenfüreinenzweiwöchigenSprint)

n Teilnehmer: ScrumMaster (alsModerator),ProductOwner,Entwicklungsteam

n BeispielVorgehen:• Setthestage:DerScrumMastereröffnetdieRetrospektive und stellt eineArbeitsumgebung her, in der sich alleTeilnehmerengagierenmögen.

• Gather data: Die Teilnehmer sammelnqualitative und quantitative Daten überdenletztenSprint.

• Generate insights: Die Teilnehmergewinnen Einsichten darüber, warumbestimmte positive oder negative Effekteaufgetretensind.

• Decide what to do: Die Teilnehmerentscheiden, was sie tun wollen, umnegative Effekte zu beseitigen oder zudämpfen oder um positive Effekte zuverstärkenoderzuerhalten.

• Closing: Der Scrum Master beendet dieRetrospektive und sorgt dafür, dass sichjemandumdieErgebnissekümmert.

n Empfehlungen:• Es sollten nur wenige Maßnahmenvereinbart werden, die das Team auchrealistisch im nächsten Sprint umsetzenkann.

• Es sollte auch über Stimmungen undGefühlegesprochenwerden.

• Der ScrumMaster sollte die verwendetenTechnikenvariieren.

• Es sollte geprüft werden, ob dieMaßnahmen der letzten RetrospektiveumgesetztwurdenundwelcheEffektedieMaßnahmengezeigthaben.

Artefakt: Product Backlog n Zweck: Überblick über die noch

ausstehenden Eigenschaften/Features desProdukts

n Eigenschaften:• Einträge beschreiben das Was und nichtdasWie.

• Geordnet(inderRegelnachPriorität)• Hoch priorisierte Einträge sind klein unddetailliertausgearbeitet.

• NiedrigpriorisierteEinträgesindgroßundnurgrobskizziert.

• IstGeschätzt.• TransparentfürdasEntwicklungsteamunddieStakeholder

• Enthält nur die noch offenenEigenschaften/Features (und nicht diebereitsabgeschlossenen)

n Verwendung:• Ordnung/PriorisierungdurchdenProductOwner

• SchätzungdurchdasEntwicklungsteam• BasisfürReleaseplanungund–Controlling

n Empfehlungen:• DasProductBacklogexistiertphysikalisch(Karteikarten/HaftnotizenanderWand).

• Beschränkungaufmaximal70–80Einträgepro Release (noch besser: ein bis zweiDutzend)

• Unterscheidung in Einträge, die für dasaktuelleReleasegeplantsindundsolchefürspäter(Ideen)

• UserStoriesundEpicsalsProductBacklogsItems(wennimUnternehmennichtbereitsein anderes gut funktionierendes Formatetabliertist)

• GruppierungderEinträgenachThemen• Bugs, die nicht sofort beseitigt werden,werdeninsProductBacklogaufgenommenunddurchdenProductOwnerpriorisiert.

Artefakt: Sprint Backlog n Zweck: Überblick über die noch

ausstehendenArbeitenimSprintn Eigenschaften:

• Enthält die für den Sprint ausgewähltenProduct-Backlog-Einträge sowie den PlanfürdieUmsetzung

• Geordnet(inderRegelnachPriorität)• ZeigtdenZustandderPlanumsetzung.

n Verwendung:• Wird im Sprint Planning durch dasEntwicklungsteamerstellt.

• Aktualisierung durch dasEntwicklungsteamimDailyScrum

n Empfehlungen:• DasSprintBacklogexistiertphysikalischinForm eines Taskboards(Karteikarten/Haftnotizen an der Wand)imTeamraum.

• DieReihenfolgeaufdemTaskboardbildetdie Priorisierung der Product-Backlog-Einträgeab.

• DarstellungvonSprint-ZielundDefinitionofDoneaufdemTaskboard

• UserStoriesundTasksalsEinträge(wennimUnternehmennichtbereitseinanderesgutfunktionierendesFormatetabliertist)

Seite 17 von 17

• Eigene Zeile oben auf demTaskboard fürungeplante Bugs, die noch im Sprinterledigtwerdenmüssen

Artefakt: auslieferbares Produktinkrement n Zweck:WertschöpfungfürdasUnternehmen

undden/dieKundenn Eigenschaften:

• Lieferbar (gemäßderDefinitionofDone),mindestens:

- funktionsfähig unterProduktionsbedingungen

- qualitätsgesichert- dokumentiert

n Verwendung:

• Erstellung und Qualitätssicherung imSprintdurchdasEntwicklungsteam

• Demonstration im Sprint-Review aufeiner vorher vereinbarten Test- undIntegrationsumgebung, um FeedbackzumProduktzubekommen

n Empfehlungen:• Automatisierte Unit Tests und

Continuous Integration als InstrumentezurQualitätssicherung(inkl.Regression)

• Testgetriebene Entwicklung undRefactoring, um bei inkrementellerEntwicklung eine Erosion derEntwurfsqualitätzuvermeiden

• Notwendige Dokumentation über dieDefinitionofDonevereinbaren