Een voorbeeldchecklist voor Scrum Masters
Michael James(mj@seattlescrum.com)
Revised 8 Feb 2022
http://ScrumMasterChecklist.org
Nederlandstalige vertaling: Frederik Vannieuwenhuyse
Versie vertaling: 10 feb 2022

Een fulltime begeleider?
Een adequate Scrum Master kan twee of drie teams tegelijkertijd begeleiden. Als je tevreden bent om je rol tebeperken tot het organiseren van vergaderingen, het afdwingen van timeboxen, en het reageren op debelemmeringen die mensen expliciet komen melden, dan is een deeltijdse invulling van de Scrum Master rolvoldoende. Er zal ook niks dramatisch gebeuren of veranderen.
Als je je een team vooropstelt dat slaagt in het realiseren van doelen waarvan ze voorheen niet beseften dat dit
mogelijk is, streef er dan naar om een geweldige Scrum Master te zijn.
Een geweldige Scrum Master is een Scrum Master van maximaal één team.
Onze aanbeveling is om bij de start één toegewijde Scrum Master te voorzien per team van ongeveer zes
personen.
Als Scrum Master, als je nog niet al het werk hebt ontdekt dat er mogelijks te doen is, stem dan af op je ProductOwner, je team, de engineering praktijken van je team en de organisatie buiten je team. Zoiets als één recept als
oplossing voor iedereen of elke situatie, bestaat niet. Hieronder zijn typische aspecten beschreven die Scrum
Masters vaak over het hoofd zien.
Aanbevolen werkwijze: Markeer elk vakje met √, ∆, ? of N.v.t., zoals beschreven op de laatste pagina.

Deel I -- Hoe gaat het met mijn Product Owner?
Scrum Masters verbeteren de effectiviteit van een Product Owner op vele manieren.

☐ Is er, ongeacht het aantal teams, één (en slechts één ) producteigenaar voor het product?
1☐ Is de Product Backlog geordend volgens de meest recente inzichten?
nieuw ontdekte eisen en wensen vastgelegd in de Product Backlog? Denk eraan: een backlog is☐ Wordencontinue in beweging en krijgt vorm volgens opkomende inzichten.
de grootte van de Product Backlog beheersbaar? Om een beheersbaar aantal items te hebben, zijn items☐ Isnaar boven toe gedetailleerder, met algemenere items (“epics”) meer onderaan in de backlog. Het biedt geenvoordeel om items lager in de Product Backlog te over analyseren. Plannen zullen veranderen door een
voortdurende conversatie tussen het ontwikkelende product en de gebruikers/klanten.
vereisten (voornamelijk deze bovenaan de Product Backlog) kan je beter beschrijven als user stories☐ Welkedie onafhankelijk, onderhandelbaar, waardevol, schatbaar, klein en testbaar2 zijn?
je jouw Product Owner uitgelegd wat technical debt is en hoe dit te voorkomen? Een mogelijkheid is om☐ Hebhet voorzien van geautomatiseerde tests en refactoring op te nemen in de De nitie van “Done” voor elk
backlog item.

☐ Biedt de backlog inzicht in informatie, rechtstreeks toegankelijk en zichtbaar voor alle betrokkenen?

1 https://seattlescrum.com/Why-Scrum-Isnt-Making-Your-Company-Very-Agile/
2 https://xp123.com/xplor/xp0308/index.shtml

fiCopyright © 2004-2022 Michael James. Vrijelijk en ongewijzigd te verspreiden.

je een geautomatiseerd systeem gebruikt voor backlog beheer, weet iedereen op welke manier dit☐ Indien
gemakkelijk te gebruiken is? Geautomatiseerde beheerssystemen vergroten het risico om informatie teverbergen en hinderen een productieve samenwerking.
je helpen om informatie meer te verspreiden door te tonen hoe grote zichtbare informatiegra eken te☐ Kan
maken?
je jouw Product Owner al geholpen met het organiseren van backlog items in gepaste release of☐ Hebprioriteitsgroepen?
iedereen op de hoogte of het release plan nog realistisch is? Je kan iedereen Product/Release Burndown☐ Isgra eken tonen nadat items als “done” beschouwd zijn tijdens elke Sprint Review. Gra eken tonen de3vooruitgang van effectief opleverde Product Backlog items. Nieuwe items die toegevoegd zijn maken
wijzigingen in scope en planning zichtbaar.
jouw Product Owner het release plan aangepast na de laatste Sprint Review? Product Owners die op tijd
☐ Heeftvoldoende geteste producten opleveren, herplannen de release elke sprint.
je Product Owner een release prognose bijgesteld na de laatste Sprint Review? Als je een goed getest☐ Heeftproduct op een vaste datum wilt a everen, moet je voortdurend de scope heroverwegen. Dit vereist
waarschijnlijk uitstel van werk voor toekomstige releases als er meer belangrijk werk wordt ontdekt. Sommige
producten kunnen elke Sprint worden uitgebracht, of meerdere keren per Sprint.

Deel II -- Hoe gaat het met mijn team?
We moedigen zeker aan om het goede voorbeeld te geven wat betreft onderlinge samenwerking met teamleden.
Er is wel een risico dat je verloren geraakt in technische taken. Denk na over jouw belangrijksteverantwoordelijkheden ten opzichte van het team:☐ Is jouw team in een toestand van ow? Enkele kenmerken van deze toestand:4• Duidelijke doelen (verwachtingen en afspraken zijn waarneembaar en doelen zijn haalbaar, passend bij
iemands vaardigheden en capaciteiten).
• Concentratie en focus, doelgerichtheid door hoge concentratie op een beperkt aandachtsgebied.
• Een verlies van zelfbewustzijn waarbij men zich geheel focust op de bezigheid en zichzelf vergeet (hetsamensmelten van actie en bewustzijn).
• Directe en onmiddellijke feedback (succes en falen zijn direct duidelijk, zodat men daarop het eigen
handelen en gedrag direct kan aanpassen).
• Een gevoel van uitdaging waarbij het wel haalbaar is (een evenwicht: niet te moeilijke, maar ook niet temakkelijke bezigheden)• Het gevoel van persoonlijke controle over de situatie en/of activiteit.
• De bezigheid is intrinsiek de moeite waard en belonend, het voelt niet als een last.

☐ Kunnen teamleden het met mekaar vinden, samen plezier hebben en elkaars succes te vieren?
☐ Houden teamleden elkaar verantwoordelijk voor hoge normen en dagen ze elkaar uit om te groeien?
☐ Zijn er problemen/onbenutte opportuniteiten die het team niet bespreekt omdat deze te oncomfortabel zijn?

5☐ Heb je verschillende werkvormen en locaties geprobeerd voor Sprint Retrospectives?

6

3 Mike Cohn, Agile Estimation and Planning. (2005).
4 Mihaly Csikszentmihalyi, Flow: The Psychology of Optimal Experience (1990).
5 Marshall Rosenberg, Nonviolent Communication: A Language of Life: Life-Changing Tools for Healthy Relationships (2003).

Overweeg ook om een professionele begeleider in te schakelen die ongemakkelijke gesprekken comfortabeler kan maken.
6 Derby/Larson Agile Retrospectives: Making Good Teams Great (2006).

fifi

fl

fl

fi

Copyright © 2004-2022 Michael James. Vrijelijk en ongewijzigd te verspreiden.

het team de focus op het Sprint doel? Overweeg een tussentijdse Sprint checkup om het Sprintplan☐ Houdtopnieuw te beoordelen.
het Sprint-taakbord wat het team doet? Let op voor "verborgen werk" van niet zichtbare taken en☐ Weerspiegelt
taken die langer duren dan een dag werk. Taken die ongerelateerd met de Sprint en het Sprint doel, vormen
een belemmering voor de Sprint.
het team uit 3-9 mensen met een voldoende mix van vaardigheden om een potentieel leverbaar☐ Bestaat
product increment te creëren?

☐ Is het takenbord van het team up-to-date?
☐ Zijn de artefacten m.b.t. zelfmanagement zichtbaar voor het team, en handig voor het team om te gebruiken?
deze artefacten voldoende beschermd tegen inmenging van buitenaf? Te veel controle van de dagelijkse☐ Zijnactiviteiten door mensen buiten het team kan de interne transparantie en zelfsturing van het team
belemmeren.
teamleden zich vrijwillig aan voor taken? In mijn eerste Scrum-team voelden we ons als vrijwilligers die☐ Biedenook betaald werden. Als het niet zo voelt, is er ergens iets misgegaan.
de nood aan a ossing van technische schuld expliciet gemaakt in de de nitie van ‘done’, waardoor de code☐ Isgeleidelijk verbetert en aangenamer wordt om in te werken?
teamleden hun functietitel achterwege in het team? Is er een gezamenlijke verantwoordelijkheid voor
☐ Latenalle aspecten van het overeengekomen werk (testen, gebruikersdocumentatie, enz.)?

Deel III -- Hoe gaat het met onze engineering praktijken?
het systeem in ontwikkeling een "push-to-test"-knop waarmee iedereen (het team zelf of een ander☐ Heeftteam) gemakkelijk kan detecteren wanneer ze een regressiefout hebben veroorzaakt (voorheen werkendefunctionaliteit die nu gebroken is)? Meestal wordt dit bereikt via het xUnit-framework (JUnit, NUnit, enz.).
er een goede balans tussen geautomatiseerde end-to-end systeemtests (ook wel "functionele tests"☐ Isgenoemd) en geautomatiseerde unit-tests?
het team zowel systeemtests als unit tests in dezelfde taal als het systeem dat ze ontwikkelen? De☐ Schrijftsamenwerking wordt er niet beter op door het gebruik van propriëtaire scripttalen of tools waarvan alleen een
deel van het team weet hoe deze te onderhouden.

☐ Heeft het team de nuttige grijze zone tussen systeemtests en unittests ontdekt?

7

een continue integratieserver automatisch alarm als iemand een regressiefout veroorzaakt? Kan deze
☐ Slaatfeedback lus teruggebracht worden tot uren of minuten? ("Dagelijkse builds zijn voor watjes." - Kent Beck)8☐ Toont de continue integratieserver het resultaat van alle tests?
teamleden het plezier ontdekt van het continue ontwerpen en constante refactoring , als alternatief☐ Hebbenvoor "Big Up Front Design”? Refactoring heeft een strikte de nitie: het veranderen van de interne structuur
9zonder het externe gedrag te veranderen. Refactoring moet meerdere keren per uur plaatsvinden, telkens
wanneer er dubbele code is, complexe voorwaardelijke logica (zichtbaar door te veel inspringing of lange
methodes in code), slecht benoemde identi ers, overmatige koppeling tussen objecten, enz. Refactoring
toepassen met vertrouwen is alleen mogelijk met behulp van geautomatiseerde testing. Het laten links liggen

8 http://www.martinfowler.com/articles/continuousIntegration.html
9 Martin Fowler, Refactoring: Improving the Design of Existing Code (1999).

fifi

fi

flCopyright © 2004-2022 Michael James. Vrijelijk en ongewijzigd te verspreiden.

van refactoring maakt het moeilijk om het product in de toekomst te veranderen; voornamelijk omdat het
moeilijk is om goede ontwikkelaars te vinden die aan code willen werken die slecht onderhouden is.
de De nitie van "Done" voor elk Product Backlog item volledig geautomatiseerde testing en☐ Omvatrefactoring? Het leren en toepassen van Test-Driven Development (TDD) maakt dit realistischer.
teamleden meestal per twee? Wordt mob-programming toegepast? Dit kan de☐ Programmeren
onderhoudbaarheid van code drastisch verhogen en het aantal bugs verlagen. Het daagt de grenzen vanmensen uit. Soms lijkt pair-programmering langer te duren (wanneer we meten volgens aantal regels code inplaats van opgeleverde functionaliteit). Geef het goede voorbeeld door het initiëren van werkdagen met pairingof mobbing sessies met teamleden. Bij sommigen zal deze manier van werken de voorkeur beginnen tegenieten.

Deel IV -- Hoe gaat het met de organisatie?
er voldoende communicatie tussen teams plaats? “Scrum of Scrums” is slechts één manier om dit te☐ Vindt
bereiken en zelden de beste.10☐ Zijn teams in staat om zelfstandig werkende features te produceren, zelfs over architecturale grenzen heen?

11

je een algemene retrospectieve uit om team overstijgende, organisatorische en systemische problemen☐ Voerop te lossen?
12de organisatorische belemmeringen waar nodig op de muur van het kantoor van de directeur☐ Wordenzichtbaar gemaakt? Kunnen de kosten worden gekwanti ceerd in Euros, verlies in tijd om iets op de markt tebrengen, verloren kwaliteit of andere gemiste opportuniteiten? (Leer wel uit de fouten van Ken Schwaber: "Eendode Scrum Master is een nutteloze Scrum Master."13)jouw organisatie één van de weinige met loopbaanmogelijkheden die compatibel zijn met teams die☐ Iscollectieve doelen stellen? Antwoord 'nee' als er een carrière-beloning14 bestaat om programmeer- ofarchitectuurwerk te doen ten koste van testen, testautomatisering of het voorzien van gebruikersdocumentatie.
jouw organisatie door de vakpers of andere onafhankelijke bronnen erkend als één van de beste☐ Iswerkplekken of als leider in jouw sector of branche?

☐ Creëer je een lerende organisatie?
Conclusie
Als je de meeste van deze items kunt afvinken en je hebt nog tijd over tijdens de dag, dan hoor ik graag van je.
Er is geen standaardformule om menselijke vindingrijkheid te laten ontspruiten. Dit document somt de punten op
die in jouw situatie wel of niet relevant zijn.
Als je eenmaal begint te beseffen wat je allemaal zou kunnen doen om een verschil te maken, heb je misschieneen terughoudendheid om het daadwerkelijk te doen. Dit is een teken dat je op de goede weg bent.

10 See http://less.works/less/framework/coordination-and-integration.html for alternatives.
11 https://less.works/less/structure/feature-teams
12 https://less.works/less/framework/overall-retrospective/
13 Ken Schwaber, Agile Project Management with Scrum (2004)
14 Ale Kohn, Punished By Rewards: The Trouble with Gold Stars, Incentive Plans, A's, Praise, and Other Bribes (1999)

fififi

Copyright © 2004-2022 Michael James. Vrijelijk en ongewijzigd te verspreiden.

Formulier organisatiebelemmering
Probleem:

Hoofdoorzaak (gebruik vijf keer "Waarom?"):Bedrijfsimpact:

Emotionele impact:

Duidelijk, uitvoerbaar verzoek:

Formulier organisatiebelemmeringProbleem:

Hoofdoorzaak (gebruik vijf keer "Waarom?"):Bedrijfsimpact:

Emotionele impact:

Duidelijk, uitvoerbaar verzoek:

Copyright © 2004-2022 Michael James. Vrijelijk en ongewijzigd te verspreiden.

Formulier organisatiebelemmering
Probleem:

Hoofdoorzaak (gebruik vijf keer "Waarom?"):Bedrijfsimpact:

Emotionele impact:

Duidelijk, uitvoerbaar verzoek:

Formulier organisatiebelemmering
Probleem:

Hoofdoorzaak (gebruik vijf keer "Waarom?"):Bedrijfsimpact:

Emotionele impact:

Duidelijk, uitvoerbaar verzoek:

Copyright © 2004-2022 Michael James. Vrijelijk en ongewijzigd te verspreiden.

Formulier organisatiebelemmering
Probleem:

Hoofdoorzaak (gebruik vijf keer "Waarom?"):Bedrijfsimpact:

Emotionele impact:

Duidelijk, uitvoerbaar verzoek:

Formulier organisatiebelemmering
Probleem:

Hoofdoorzaak (gebruik vijf keer "Waarom?"):Bedrijfsimpact:

Emotionele impact:

Duidelijk, uitvoerbaar verzoek:

Copyright © 2004-2022 Michael James. Vrijelijk en ongewijzigd te verspreiden.

INSTRUCTIESAls je deze checklist als opdracht hebt gekregen en je huidige (of meestrecente) werkgever heeft iets als Scrum geprobeerd, pas dit dan toe op wat
je daar hebt gezien. Markeer elk item met één van de volgende:√(“goed genoeg”)∆(“kan worden verbeterd en ik weet hoe te beginnen”)?

("kan worden verbeterd, maar hoe is nog niet duidelijk”)

N.v.t. ("niet van toepassing" of "levert geen voordeel op")

Of, als jouw huidige (of meest recente) werkgever nog nooit zoiets als
Scrum heeft geprobeerd, markeer dan elk item met één van de volgende:√("goed bezig" of “geen problemen om dit goed te doen")∆(“lijkt een uitdaging en ik weet hoe ik moet beginnen”)?

("lijkt een uitdaging en ik weet niet hoe ik moet beginnen")

N.v.t. ("niet van toepassing" of “zou geen voordeel opleveren")

Wanneer je alle items in de lijst hebt aangeduid, noteer dan 2-6
organisatorische belemmeringen aan op de bijgevoegde formulieren,
ongeacht of deze al dan niet zijn afgeleid uit deze checklist. Kies
belemmeringen waarvan je ten minste 1% hoop hebt om iets veranderen.

Copyright © 2004-2022 Michael James. Vrijelijk en ongewijzigd te verspreiden.