Voor iedereen die met Scrum gaan werken.

2. GEEN GARANTIE VOOR SUCCES!
 Maar wel garantie om alle issues & risico’s zsm te
identificeren
 Falen met Scrum gaat beter dan met traditionele methoden.
Zonder verrassingen aan het eind van het project
 Scrum invoeren is verandermanagement/risicomanagement

3. KEEP IT SIMPLE
 3 rollen
 Product Owner, Development Team, Scrum Master
 2 lijsten
 Product Backlog, Burndown Chart
 4 meetings
 Sprint Planning, Daily Scrum, Sprint Review, Sprint
Reprospective
 GEEN projectmanager!

4. TRADITIONEEL VS SCRUM

5. 3 ROLLEN
 Product Owner
 Development Team
 Scrum Master

6. PRODUCT OWNER 1/3
 Eigenaar van de business case/probleem en verantwoordelijk voor 1 product
 Vertegenwoordigt de stakeholders/business en hakt knopen door
 Verantwoordelijk voor wat, binnen budget, deadline
 Legt over met partners, marketing, etc.
 Geen bottleneck! Moet 100% beschikbaar zijn
Backlog Management
 Backlog is een communicatiemiddel en is openbaar
 Prioriteren van de items met hoogste waarde & relatief de laagste kosten.
Quickwins!
 Zorgen voor een schatting inspanning door het Development Team

7. PRODUCT OWNER 2/3
Stakeholder Management
 Bepalen van alle stakeholders mbv een brainstorm sessie. Denk aan
architecten, wetgeving, sales, beheer etc.
 Inplannen van meetings; Sprint Planning en Sprint Review (demo)
 Zorgen dat ze naar de Daily Scrum komen
Development Team
 Inplannen van vaste momenten voor meetings/werkafspraken
 Gebruiken van technieken bij schattingen inspanning. Bijv. Planning
Poker
 Zorgen voor een eenduidige interpretatie en goedkoopste
implementatie

8. PRODUCT OWNER 3/3
Release Management
 Zorgen voor een korte releaseperiode met minimale mogelijke set
van eisen
 MMF: Minimal Marketable Features
 MVP: Minimal Viable Product
 Stellen van mijlpalen
 Voortdurend uitleggen van waarom je product/visie
 Laat je stakeholders aan het woord tijdens Sprint Planning meetings
 Zorgen voor een nauwe samenwerking met de Scrum Master
 Zsm een versie op de Acceptatieomgeving krijgen

9. DEVELOPMENT TEAM
 Multidisciplinair, 5-9 personen en tijdelijke inhuur is mogelijk
 Vaste teams
 Werken met “story points” ipv echte tijd
 Doen alles van A tot Z
 Bepalen hoe/wie gaat het doen
 Afgeven van schattingen
 Autonoom/zelfsturend

10. SCRUM MASTER
 Zorgen dat Scrum goed wordt toegepast
 Team kennis laten maken met Scrum (bv. mbv XP Game)
 Proactief en faciliterend voor het Development Team & Product Owner
 Helpen met Daily Scrum (stand-up) en formuleren van eisen
 Wegnemen van belemmeringen, ook bv. trage internet, geen ruimte etc.
5 Scrum Principes
 Toewijding: iedereen neemt zijn verantwoordelijkheid
 Focus: werken aan 1 product, 1 sprint, 1 item tegelijk in 1 team
 Openheid: Transparantie
 Respect: Respect voor ervaring/achtergrond en toon interesse
 Moed: Beetje lef kan geen kwaad bij verbeteringen/veranderingen

11. 2 LIJSTEN
 Product Backlog (input voor Sprint Backlog)
 Release Burndown Chart (input voor Sprint Burndown Chart)
 Sprint-lijsten worden bijgehouden door het Development Team!

12. PRODUCT BACKLOG 1/6
 Product Owner is de eigenaar
 Lijst van alle taken (eisen & wensen) om het product te kunnen
maken
 Dynamische lijst met prioriteiten en schattingen
 Bestaat uit “Product Backlog items” = user story (functionele eis)
 “wat” wordt beschreven en niet “hoe”
 Communicatiemiddel
 Product Backlog bestaat uit:
 Wensen (features)
 Eisen (qualities)
 Problemen (bugs, issues)

13. PRODUCT BACKLOG 2/6
Prioriteren
 Gebruik echte sortering! Geen MoSCoW met allemaal must-have’s
 Houd je lijst kort. Cluster de zaken die bij elkaar horen samen met
alle stakeholders (mbv “Silent Clustering”)
 Waarde voor business bepaalt de volgorde
 Een redelijk project heeft max. 80 items
 Bij onduidelijke items vraag 5x waarom?
 User story: “Als een (rol) wil ik (wens/feature) zodat
(voordeel/benefit)”
 Begin met de benefits en acceptatiecriteria bij een user story

14. PRODUCT BACKLOG 3/6
Inschatten
 De hele Backlog moet worden ingeschat in story points (bv. mbv
Planning Poker / Wideband Delphi)
 Je schat niet alleen je eigen werk maar van het hele team
 Bepaal waarde van een “story point” in dagen.
 Bijv. Story point = 1,5 mandag. In 1 week met 4 personen heb je 20
mandagen dus 20x1,5= 35 story point. Als per week 35 punten
gehaald kan worden, is dat de velocity (snelheid) van het team
http://www.scrum-institute.org/Effort_Estimations_Planning_Poker.php

15. PRODUCT BACKLOG 4/6
Product Backlog Refinement
 Initiële schattingen en nieuwe stories behandelen
 Splitsen naar nieuwe onderdelen en oude weggooien ivm minder
ballast en archief
 Spike: een beperkte hoeveelheid tijd om een probleem te begrijpen.
Deze tijd wordt niet meegeteld voor de velocity
 Inplannen direct na Daily Scrums of vaste tijdstippen

16. PRODUCT BACKLOG 5/6
Sprint Backlog
 Deze lijst wordt tijdens de Sprint Planning gemaakt
 Bovenste items of items die een thema vormen worden gekozen
 Aantal items worden bepaald adhv de velocity. Gebaseerd op de
behaalde resultaten van de laatste sprint. Update de nieuwe sprint
met bezetting (vakantie, ziekte, training)
 Items worden vertaald naar taken die het “hoe” beschrijven
 Werkverdeling en voortgang wordt bewaakt: To Do, Doing, Done
 Team kan onderling indicatie geven in punten of uren
 Voor rapportages maak foto van het bord ipv Excel

17. PRODUCT BACKLOG 6/6
Definition of Done
 Opgesteld door Product Owner en het Development Team
 Eisen die altijd gelden bijv. Documentatie bijwerken, Functionele test,
Performance test, Code review, Gebruikersacceptatietest
 Hang de Definition of Done naast de Sprint Backlog
 Performancetest tools: JUnit, NUnit, FitNesse, Cucumber, JMeter
 Testen in sprint 6 betekent, testen 1 t/m 6

18. VOORBEELD PRODUCT BACKLOG

19. BURNDOWNS
 Product Owner is de eigenaar
 Bijhouden van voortgang
 Voortgangsrapportage = MBWA (Management By Walking
Around – Genchi Genbutsu)
 Release Burndown is voor het bewaken van de voortgang
 Sprint Burndown is voor het bewaken van de voortgang
binnen een sprint

20. VOORBEELD PRODUCT BURNDOWN CHART

21. 4 MEETINGS
 Sprint Planning
 Sprint Planning I
 Sprint Planning II
 Daily Scrum
 Sprint Review
 Sprint Reprospective
 max. 2 uur meeting voor een sprint van 2 weken

22. VOORBEELD AGENDA VOOR DE SPRINT

23. SPRINT PLANNING I – WAT?
 Scope bepalen met de stakeholders (vaak het bovenste gedeelte
Backlog)
 Velocity is de hoeveelheid werk voor een sprint
 Wel ruimte overlaten voor items die wegvallen/erbij komen bij de 2e
meeting

24. SPRINT PLANNING II – HOE?
 Implementatie/oplossing bepalen
 Werkverdeling
 Analyse/uitzoekwerk krijgt geen punten (spike)
 Een story valt vaak uiteen in 5 delen. Kleine taken van 2-4 uur zijn
ideaal om te managen
 Indien nodig kunnen de taken in uren geschat worden
 Team spreekt haar commitment uit aan de Product Owner

25. DAILY SCRUM (STAND-UP)
 Openbaar, staand, cirkelvorm, dichtbij Scrum Bord, max. 15 minuten
 Wat heb je sinds de vorige Daily Scrum gedaan?
 Wat ga je vandaag doen?
 Zijn er belemmeringen?
 Invulling van de dag aangeven, geen voortgangsrapportage of
verantwoording maar synchroniseren!
 Weet wat je gisteren gedaan hebt 
 Het Scrum bord wordt door het team bijgewerkt, dus niet alleen door
de Scrum Master
 Er is geen voorzitter. Team moet onderling vergaderen

26. VOORBEELD SCRUM BORD
Scrum Bord wordt vaak ingedeeld in 3 blokken:
Sprint Backlog, Sprint Burndown en Definition of Done (DoD)

27. SPRINT REVIEW (DEMO)
 Einde van de sprint
 Demo aan de stakeholders (gebruikers/business). Interactief houden en liever een
stakeholder achter de PC zetten
 Probeer tijdens de demo’s 1 PC en 1 omgeving te gebruiken
 Zoveel mogelijk feedback krijgen van de Product Owner en de stakeholders
 Sprinten verbeteren
 Team moet bereid zijn om elk moment in de sprint een demo te kunnen geven,
namelijk van de “done” items op de testomgeving
 Geen resultaten laten zien van de niet “done” items
 Niet verdedigen maar parkeren! Bespreek het offline
 Acties bepalen o.a. wel/niet naar productie gaan, extra Refinement sessie nodig
 Bug  Het werkt niet / Change  Het werkt wel, alleen anders

28. SPRINT RETROSPECTIVE (RETRO)
 Lessons Learned
 Continu verbeteren. Efficiëntie is leuk maar effectiviteit veel beter!
 Actielijst bespreken (vorige retro’s) en nieuwe acties bepalen
 RETRO (Agile Retrospectives)
 Setting the Stage
 Gather Data
 Generate Insights
 Decide What to Do
 Ook handig in 2 delen vergaderen. Met en zonder de Product Owner
 Retro technieken zijn handig. Bijv. Mad, Glad, Sad mbv Post-Its op het bord
 Goede dingen ook bespreken en mensen bedanken!

29. SCRUM PROCES

30. WAAROM SCRUM? 1/2
 Meer waar voor je geld
 duidelijk items, sneller oplevering, belangrijkste punten eerder oppakken
 Meer controle
 snellere feedback
 Tevreden gebruikers
 dmv Sprint Reviews mening/feedback krijgen
 Hogere kwaliteit
 ivm iteraties vaker verbeteren
 Business case validatie
 na een paar weken weet je of het product haalbaar is tov alleen papierwerk
 Meer aansluiting bij opdrachtgever
 geen afstand tussen opdrachtnemen er klant

31. WAAROM SCRUM? 2/2
 Minder bureaucratie
 focus en transparantie
 Schalen van kleine organisaties
 ideaal voor organisaties zonder processen
 lef, focus, autonomie
 Kennisdeling
 door samenwerking met verschillende disciplines
 het leren op je specifieke vakkennis wordt minder, aparte kennissessies zijn
erg relevant
 Meer lol
 autonomie, passie & vakmanschap.
 samenwerken met teamleden en klanten

32. AGILE MANIFESTO
 Mensen en onderlinge interactie boven processen & tools
 Werkende software boven complete documentatie
 Samenwerking met de klant boven contractonderhandelingen
 Inspelen op verandering boven volgen van een plan

33. LETS SCRUM…!
Meer informatie:
Scrum voor Dummies – Michael Franken
https://www.scrum.org/Scrum-Guide
http://www.scrum-institute.org/index.php