prinzipien scrum ergebnisse - das scrum plakat · product owner sprint backlog product backlog...

Product owner

Sprint Backlog

Product BacklogScrum Master

Team

Daily Scrum Meeting

Sprint Review

Sprint Retrospective

potenziell auslieferungs-fähiges Produkt

Sprint PlanningMeeting 1 & 2

Sprint

No Changes

Taskboard

Impediment Backlog

Burndown Chart

Meetings

Prinzipien

Scrum

Erg

eb

nis

seP

erso

ne

n

• DerProductOwner(PO)vertrittalleInteressengruppen

außerhalbdesProjektteams

• ErgibtdieVisionvor

• Wasmussentwickeltwerden,umgeschäftlichenErfolgzuhaben?

• DerPOformalisiertdieseAnforderungenineinerListe

vonFeatures,dem„ProductBacklog“

• DieAnforderungenwerdennachGeschäftswertpriorisiert

• ÄnderungenimProductBacklogsindzujederZeiterlaubt

Product Owner

• DasProductBacklog(PBL)beinhaltetalleerwünschtenFeatures

undzulieferndenErgebnisse

• DerPOpriorisiertdieEinträgenachdemgeschäftlichen

NutzenundderBewertungdesRisikos

• Einträgekönnenjederzeitgeändert,hinzugefügtoderentferntwerden

• DasPBListeinkontinuierlichgepflegterPlanum

denmaximalengeschäftlichenNutzenzuerreichen

Product Backlog

• BeinhaltetdieAufgabendienotwendigsind,umdasvereinbarte

Sprint-Zielzuerreichen

• EinträgegruppiertnachPBL-Einträgen

• BildetdieBasisfürdie(Selbst-)OrganisationdesTeams

währenddesSprints

• DarstellungaufdemTaskboard(Post-ito.Ä.)

Sprint Backlog

• DasImpedimentBacklog(IBL)listetdieidentifiziertenHindernisse

• imTeam

• inderOrganisation

• DasTeampriorisiertdasIBL

• DieBeseitigungvonIBL-Einträgenkannzuneuen

AufgabenimSprintBacklogführen

• WirdvomScrumMastergepflegtundverwaltet

Impediment Backlog

• DasBurndownChart(BDC)zeigtdennochzuerbringenden

RestaufwandfürdenaktuellenSprint

• GraphischeDarstellung,wirdtäglichaktualisiert

• SollteamEndedesSprintsaufNullstehen

Burndown Chart

• Voraussetzungistein„sauberes“ProductBacklog.D.h.essollte

• existieren,

• nachGeschäftswertpriorisiertsein,und

• jederEintragsollteeinAbnahmekriteriumenthalten(„howtodemo“)

• AnschließendwerdendieeinzelnenEinträgevomTeambeschätzt

• z.B.mitPlanningPoker

• ProductOwnerstehtfüretwaigeRückfragenbereit

• DasTeamwähltdannsovieleEinträgeausdemPBLaus,

wieesdenktimSprintumsetzenzukönnen

Sprint Planning Meeting 1

• Detailplanung

• EinträgedesSprintBacklogswerdeninAufgaben

vonmaximal1TagAufwandaufgebrochen

• AmEndederPlanungsollmanFolgendeserreichthaben

• ManhateinZielfürdenSprinterstellt

• sichaufeinSprintBackloggeeinigt

• TerminefürSprintReviewunddastäglicheStatusmeetingausgemachtund

• eineListederTeammitgliedersamtderenVerfügbarkeitzusammengestellt

Aber:

• BevoresendgültiglosgehtwirddasSprintBacklognochmalsvom

ProductOwnerabgenommen

Sprint Planning Meeting 2• täglich,stehendvordemTaskboard,immer<15min.

• 3Fragen:

• Washabeichseitgesternerledigt?

• Wasmacheichbismorgen?

• Wasbehindertmich/hatmichbehindert?

• AntwortenbewegenPost-its/AufgabenaufdemTaskboard.

• MeetingimTeamfürdasTeam(nichtzurStatuskontrolle)

• DasTeamaktualisiert

• SprintBacklog

• BurndownChart(WievieleAufgabensindnochzuerledigen?)

• ListederHindernisse(ImpedimentBacklog)

Daily Scrum Meeting

•Präsentationund„Abnahme“derfertiggestelltenProduct-Backlog-Einträge

•ÜberprüfungdesSprint-Zieles

•Präsentationineiner„echten“Umgebung

•FeedbackderBeteiligten,evtl.neueEinträgeimPBL

Sprint Review

• VereinbartesSprint-ZielundSprint-Endewerdennichtverändert

• ErmöglichtdemTeam,füreinengewissenZeitraumungestörtzuarbeiten

• DasProductBacklogdarfzujedembeliebigenZeitpunktgeändertwerden

• DieseÄnderungenwerdenaberfrühestensimnächstenSprintbearbeitet

• BeikritischenEreignissenkannderPOdenSprintabbrechen(unddirektdennächstenSprintstarten)

No Changes• Sprintshabeneinekonstante,vomTeamundPOzuBeginnfestgelegteDauer

• ScrumschlägtvierWochenvor.ÜblichsindSprintsvoneinbisvierWochen

• Sprintsfolgendirektaufeinander

• WichtigisteinnachhaltigesTempo,dasaufDauerdurchgehaltenwerdenkann

• SoentstehteinfesterRhythmusinderEntwicklung

SprintKreativeZielanalyse

• Ideenmanagement

• Stakeholdermanagement

• NutzungvorhandenerPrototypenetc.

Start

Extrem schlanker Prozess• 3 Rollen• 4 Artefakte• wenige Regeln

• EristCoachfürdieAnwendungvonScrum

• ErhilftdemTeamdurch:

• BeseitigungderorganisatorischenHindernisse

• SchutzvorstörendenEinflüssenundVersuchen

der„Einmischung“

• ErarbeitetmitdemProductOwnerzusammenundunterstützt

diesenbeiderPriorisierungnachgeschäftlichenNutzen

• ErkontrolliertZyklenvon„inspectandadapt“inScrum

• ErsorgtfürdieUnterstützungundAnerkennungderagilen

PrinzipiendurchalleProjektbeteiligten

Scrum Master

• OptimaleGröße:7+/-2Mitglieder

• Interdisziplinärbesetzt

• AlleFähigkeiten,umdasfertigeProduktzuerstellen

sindvorhanden(Architekten,Entwickler,Tester,…)

• DasTeammussdieVisiondesPOverstehen

• DasTeamorganisiertundverwaltetsichselbst

• DasTeamverpflichtetsich,vereinbarteZielezuerreichen

• JederträgtmitseinemgesamtenWissenzumErfolgbei

(unabhängigvonhierarchischerPositionundformellerQualifikation)

• Vertrauenskultur:Eswirddavonausgegangen,dassjederimmer

seinBestesgibt

Team

Sprint Retrospective•ErfahrungendesletztenSprintsführenzukonkretenVerbesserungen:

•ObersteDirektive–UnabhängigdavonwasinderRetrospektive

angesprochenoderdiskutiertwird,sindwirderÜberzeugung,dassjeder

unterdengegebenenUmständenseinBestesgegebenhat,umdasZiel

desSprintszuerreichen

•DreiFragen(Zeitachse):

•Wasistgutgelaufen?

•Waskannverbessertwerden?

(Team/Organisation)

•Werpacktesan?

• DasErgebniseinesSprintsistdiefertigeRealisierung

derimSprintzielvereinbartenFeatures.

• Fertigheißtpotenziellauslieferbar,fertigfürdenRollout:

• fertigimplementiert

• fertiggetestet

• CodeentsprichtStandardsundRichtlinien

• ausreichenddokumentiert

• DieDefinitionvon„fertig“erfolgtdurchdasTeam

(undkannsichverändern/verbessern)

potenziell aus-lieferungsfähiges Produkt

©CopyrightInterFaceAG•V.0.1-090707www.InterFace-AG.de

www.scrum-poster.de

Scrum ñ Sprint Retrospective

Scrum – Product Owner

Der Product Owner gibt die Vision vor – was muss entwickelt werden, um maximalen Erfolg zu haben

„Manifesto for Agile Software Development“

We are uncovering better ways of developing software by doing it and helpingWe are uncovering better ways of developing software by doing it and helpingothers do it. Through this work we have come to value:

Individuals and interactions over processes and toolsIndividuals and interactions over processes and tools

Working software over comprehensive documentation

C t ll b tiCustomer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Prinzipien des „lean development“

• Eliminiere Verschwendung• Verinnerliche Qualität

E Wi• Erzeuge Wissen• Vermeide frühe Festlegungen• Liefere schnell

R kti d hät di M h• Respektiere und schätze die Menschen• Folge dem Pull-Prinzip• Optimiere nicht lokal, sondern global

V b t ti• Verbessere stetig• Vermeide (Lager-)Bestand

Probleme und Schwierigkeiten inProbleme und Schwierigkeiten inSoftwareprojekten

• Nicht alle Anforderungen sind ausreichend bekannt• Anforderungen ändern sich, neue kommen hinzu• Unstimmigkeiten bei der Bewertung, ob CR, Bug oder Featureg g, , g• Technische Rahmenbedingungen sind nicht klar oder ändern sich• Know-how-Träger verlassen das Team• Umfangreiche Bugfixing-Phaseng g g• Termine werden verändert• Prozesse werden nicht eingehalten oder nicht verstanden• geforderte Artefakte (Dokumentation) werden nur pro forma erstelltg ( ) p• …• …

GA ecaFretnI