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
Top Related