Handboek

Agile werkproces Application

Development

SCRUM

Naam afdeling of projectteam: Application Development

Datum: 14-2-2012
Naam auteur: Eric de Wolf
Versie: 1.0
 Handboek

Inhoudsopgave
1 Inleiding 3
2 Agile proces 3
2.1 Werkvoorbereiding 3
2.1.1 Pre-refinement en Registreren op backlog 4
2.1.2 Prioriteren backlog 4
2.1.3 Refinement 4
2.1.4 Tools 5
2.2 Realisatie 5
2.3 Sprintplanning 5
2.4 Realisatie 6
2.5 Demo 7
2.6 Regressietest 7
2.7 Retrospective 7
2.8 Specialistenteams, aannemer en onderaannemers 8
2.9 Meerdere teams voor een opdrachtgever 8
2.9.1 Tools 9
2.10 Opleveren 10
2.10.1 Acceptatie 10
2.10.2 Deployment 10
2.10.3 Tools 10
3 Bijlagen 11
1 Definition of Ready 12
2 Definition of Done 13
3 Scrum Guide – NL 14
4 Burndownchart_sprintxx.xls 15
5 Checklist SCRUM 16

Classificatie: niet openbaar pagina 2 van 16 413487271.doc

 Handboek

1 Inleiding
Binnen de afdeling Application Development AD wordt gewerkt volgens de agileaanpak SCRUM. Deze
werkwijze maakt het mogelijk om door het inzetten van een vaste structuur optimaal flexibel in te spelen
op wijzigende behoefte van de opdrachtgever, ergo bedrijfsvoering CAK.

Dit handboek beschrijft de verschillende fasen binnen het SCRUM werkproces:

 Werkvoorbereiding
 Realisatie
 Oplevering

Per onderdeel wordt aangegeven hoe de stappen binnen het proces eruit zien. Tevens worden de
verantwoordelijkheden en output producten beschreven.

2 Agile proces
Het agileproces binnen de afdeling AD wordt vorm gegeven door gebruik te maken van SCRUM.
SCRUM beslaat de fasen “Werkvoorbereiding”, “realisatie” en “opleveren”.

In dit hoofdstuk wordt het Agile werk proces beschreven.

2.1 Werkvoorbereiding
Voordat werk door een ontwikkelteam van de afdeling AD kan worden uitgevoerd, dient inzichtelijk te
zijn om welk werk het gaat.

Het inzichtelijk maken van de werkzaamheden begint met een wens voor een product vanuit de
opdrachtgever. De opdrachtgever wordt vertegenwoordigd door de product owner (PO).

De product owner beheert de lijst met bedrijfswensen (product backlog). Hierin is hij verantwoordelijk
dat de lijst op prioriteit is gesorteerd en dat de items die erop genoemd zijn voldoende duidelijk zijn voor
zowel het ontwikkelteam als de mensen die hij vertegenwoordigd (stakeholders).

De items op de product backlog worden in een standaard formaat opgesteld, de userstory. Deze
userstory heeft de volgende opbouw:

Als <rol>
wil ik dat <wat moet de gebruiker kunnen>
zodat <de reden achter de gewenste functionaliteit>

Classificatie: niet openbaar pagina 3 van 16 413487271.doc

 Handboek

2.1.1 Pre-refinement en Registreren op backlog

Alle producten, die worden gevraagd aan de afdeling AD dienen direct of indirect toegevoegde waarde
voor het CAK te genereren. Dit betekent dat iemand belang heeft bij het doorvoeren van een wijziging,
het oplossen van een bug of het analyseren van een probleem.

De persoon (vertegenwoordiger van een afdeling, team, unit, etc.) die de wensen uit is de stakeholder
voor die wens. De stakeholder is verantwoordelijk voor het aan de product owner en andere
stakeholders duidelijk maken waar zijn/haar wens voor staat en wat deze toevoegt. Het verduidelijken
en onderbouwen van een wens vindt plaats in de pre-refinement sessie.

Wanneer een userstory voldoende helder is en voldoende draagvlak heeft, dan wordt deze toegevoegd
aan de product backlog als product backlog item.

Verantwoordelijkheden
Productowner Eigenaar van en eindverantwoordelijk voor de product backlog
Stakeholder Verantwoordelijk voor een heldere vraagstelling en onderbouwing
(business case) van de vraag.
Ontwikkelteamlid Optioneel aanwezig als vraagbaak in de pre-refinement sessie
Resultaten
Product backlog De product backlog wordt uitgebreid met de besproken en
goedgekeurde items.

2.1.2 Prioriteren backlog

De product backlog bevat een groot aantal product backlog items. Aangezien slechts een beperkt
aantal userstories gelijktijdig gerealiseerd kan worden, dient de lijst volgens prioriteit gesorteerd te zijn.
De hoogste prioriteit boven aan de lijst.

De prioriteiten op de product backlog kunnen dagelijks wijzigen. Welke product backlog item het meest
belangrijk is wordt bepaald door de diverse stakeholders, gecoördineerd door de PO. De PO heeft
hiernij de eindbeslissing.

De prioriteit van een userstory veranderd in principe niet meer nadat deze in een sprint is ingepland.

Verantwoordelijkheden
Productowner Eigenaar van en eindverantwoordelijk voor de product backlog De
productowner is eindbeslisser bij het prioriteren.
Stakeholder Alle items op de backlog worden door de betreffende stakeholders
gemotiveerd, waarna een door de stakeholders gedragen
prioritering dient te ontstaan.
Resultaten
Product backlog De items op de product backlog zijn in volgorde van belangrijkheid /
toegevoegde waarde voor de organisatie gesorteerd. Het bovenste
item is het meest belangrijke voor het CAK.

2.1.3 Refinement
Backlog refinement omvat globaal inschatten van de hoeveelheid werk, het verduidelijken van de
requirements en het opbreken van grote userstories in kleinere items. Een goede userstory is niet
groter dan een kwart van een Sprint. Zoals Bill Wake aanbeveelt, moet elk story onafhankelijk,
waardevol, schatbaar, klein en toetsbaar zijn. Grote backlog items omzetten in kleine items, die toch

Classificatie: niet openbaar pagina 4 van 16 413487271.doc

 Handboek
businessvalue hebben, is in het begin moeilijk, vooral wanneer het bestaande systeem veel
achterstallig onderhoud kent.

De refinementsessie maakt de backlog items planbaar in volgende sprints en helpt zowel het
ontwikkelteam, de product owner als de stakeholders om de userstory maximaal helder te hebben.

De refinement sessie wordt ook aangeduid als grooming.

Verantwoordelijkheden
Productowner Verantwoordelijk voor het betrekken van alle relevante stakeholders
of materiedeskundigen voor de te bespreken backlog items bij de
sessie.
Stakeholder / Deze persoon(en) is verantwoordelijk voor het waar nodig
materiedeskundige toelichten van de te bespreken backlog items
Ontwikkelteam Het volledige ontwikkelteam is verantwoordelijk voor het stellen van
de vragen, die noodzakelijk zijn om de backlogitems duidelijk te
krijgen.
Resultaten
Product backlogitems De productbacklogitems zijn voor alle partijen duidelijk,
realiseerbaar en planbaar.

2.1.4 Tools
Tool Inzet
Jira + Greenhopper Alle userstories worden in Jira geregistreerd. Door
middel van de plugin Greenhopper wordt de lijst in
volgorde van prioriteit beheert.

2.2 Realisatie
De realisatiefase is het primaire domein van de afdeling AD. In deze fase wordt door een of meer
ontwikkelteams gewerkt aan de door de productowner(s) gewenste producten.

De realisatie fase vindt plaats in cycli van 2 weken. Elke twee weken vinden de onderstaande stappen
opnieuw plaats. Door het gebruik van korte iteraties is de afdeling optimaal flexibel en kan snel worden
ingesprongen op wijzigende prioriteiten van de business.

In onderstaand schema staat de cyclus (voor 3 opeenvolgende sprints) van intake tot deployment in tijd
weergegeven.

SP: sprint planning, DM: Demo, RT: Retrospective, OP: oplevering naar productie

2.3 Sprintplanning
De spintplanning is de start van elke periode van twee weken, de sprint. Tijdens deze sessie worden
vanaf de geprioriteerde product backlog items inpland voor de sprint.

Tijdens de planningssessie wordt bepaald welke product backlog items, in de sprint, door het
ontwikkelteam kunnen worden gerealiseerd. Het ontwikkelteam is verantwoordelijk voor het innemen
van het werk.

Classificatie: niet openbaar pagina 5 van 16 413487271.doc

 Handboek
Voor het inplannen van een product backlog item gelden twee criteria:
 Het item voldoet aan de Definition of Ready
 Het item past qua tijd in de sprint

Het inschatten van de benodigde tijd voor een backlog item wordt gedaan op basis van een relatieve
factor. Elk item wordt door het ontwikkelteam voorzien van een aantal punten. Deze punten geven de
relatieve grootte van de hoeveelheid werk aan ten opzichte van andere items, die ook van punten zijn
voorzien.

De relatieve punten worden storypoints genoemd. De punten zijn specifiek voor een ontwikkelteam en
kunnen dus niet over ontwikkelteams heen vergeleken worden. Het aantal punten dat in een sprint past
zal daardoor ook per ontwikkelteam verschillen. Het aantal punten dat een bepaald ontwikkelteam per
sprint kan oppakken zal na enige tijd constant zijn.

Verantwoordelijkheden
Productowner De productowner brengt de geprioriteerde product backlog in.
Tijdens de sprintplanning kan hij bepalen om de prioriteit van items
te wijzigen, zodat een sprint optimaal kan worden benut.
Ontwikkelteam Het ontwikkelteam is verantwoordelijk voor het inplannen van het
maximaal haalbare aantal backlog items binnen de startende sprint.
Het ontwikkelteam committeert zich aan de opgestelde sprint
backlog.
Resultaten
Sprint backlog Een lijst met items, waarvan het ontwikkelteam aangeeft dat deze
binnen de sprint zal worden afgerond.

2.4 Realisatie
De realisatie is het grootste onderdeel van de sprint. Tijdens de realisatie zorgt het ontwikkelteam voor
het maken van de gevraagde producten.

De producten worden ontwikkeld, getest en voorzien van een (positieve!) vrijgave. Alle producten die
door het ontwikkelteam worden vrijgegeven voldoen aan de opgestelde Definition of Done (zie bijlage
voor de minimale versie. Elk ontwikkelteam kan ervoor kiezen om deze uit te breiden.).

Tijdens de realisatie fase kan het zijn dat een sprint backlog item toch nog vragen oproept. Deze vragen
zullen worden neergelegd bij de materiedeskundige, stakeholder of product owner.

Het uitgangspunt bij elke sprint is dat alle geplande items worden opgeleverd aan het einde van de
sprint. Bij het niet tijdig kunnen afronden van een of meer items, dient dit in een zo vroeg mogelijk
stadium met de product owner te worden besproken. Gezamenlijk kan dan bepaald worden welke
maatregelen binnen de sprint worden genomen om de sprint alsnog optimaal te kunnen benutten.

Verantwoordelijkheden
Ontwikkelteam Het ontwikkelteam is verantwoordelijk voor het realiseren van de
sprint backlog items.
Productowner Antwoord geven op vragen van het ontwikkelteam, zodat de sprint
backlog items kunnen worden gerealiseerd.
Resultaten
Gerealiseerde Sprint Alle sprint backlog items voldoen aan de Definition of Done.

Classificatie: niet openbaar pagina 6 van 16 413487271.doc

 Handboek

2.5 Demo
Elke sprint eindigt met een demo van de gerealiseerde producten aan de productowner en de door hem
uitgenodigde stakeholders en overige geïnteresseerden.

De demo is het eerste acceptatiemoment door de productowner. Op basis van de demo kan de
productowner besluiten om de sprint te accepteren zodat deze door kan naar de regressietest. Indien
de de product owner de sprint niet accepteert zal in onderling overleg bepaald worden hoe de sprint
alsnog kan worden afgerond tot een acceptabel geheel.

Verantwoordelijkheden
Ontwikkelteam Het ontwikkelteam demonstreert de door haar gerealiseerde
producten.
Productowner De product owner accepteert de sprint of keurt deze af.
Resultaten
Acceptatie of afkeuring De productowner (op basis van de reactie van de diverse
sprint stakeholders) accepteert de producten of wijst deze af.

2.6 Regressietest
De regressietest behoort integraal onderdeel te zijn van elke sprint. Door de nog lange doorlooptijd
hiervan is het niet haalbaar deze binnen de sprint af te ronden. Er is gekozen om de regressietest na
afronding van de sprint uit te voeren.

Het resultaat van de regressietest kan zijn:

a) Geen bevindingen: Alle producten van de sprint worden opgeleverd
b) Wel bevindingen: Geen enkel product van de sprint wordt opgeleverd, alle bevindingen worden
in de dan lopende sprint opgelost.

Verantwoordelijkheden
Ontwikkelteam Het ontwikkelteam is eindverantwoordelijk voor de producten van
de sprint.
Regressietestteam Het regressietest team voert de regressie uit en levert een
vrijgaveadvies.
Resultaten
Vrijgaveadvies De regressietest wijst uit of de ontwikkelde producten wel of geen
negatieve uitwerking op reeds bestaande producten hebben.

2.7 Retrospective
Afsluitend aan iedere sprint houdt een ontwikkelteam de retrospective. Tijdens deze meeting wordt door
het ontwikkelteam gekeken naar de punten ter verbetering van het team en de punten die gekoesterd
moeten worden.

Het belang van deze meeting is het continu verbeteren van de prestaties van het ontwikkelteam.

Verantwoordelijkheden
Ontwikkelteam Het ontwikkelteam als geheel is verantwoordelijk voor de
zelfreflectie om te komen tot teamverbetering
Resultaten
Retro samenvatting De retro samenvatting bevat acties, die het team uitzet om haar

Classificatie: niet openbaar pagina 7 van 16 413487271.doc

 Handboek
eigen functioneren te verbeteren. Tevens bevat de samenvatting
een overzicht van de onderdelen, waar het team trots op is en goed
wil blijven doen.

Om een retrospective niet te laten vervallen tot een vaste invuloefening wordt het aangeraden om
periodiek te wisselen van vorm. Op de volgende site zijn verschillende vormen van het houden van een
retrospective te vinden: http://www.slideshare.net/prowareness/techniques-for-effective-retrospectives

2.8 Specialistenteams, aannemer en onderaannemers

Sprint backlog items kunnen werkzaamheden bevatten, die door het ontwikkelteam niet zelf kunnen
worden uitgevoerd. Het ontwikkelteam moet beroep doen op expertise die extern beschikbaar is.
Binnen het CAK zijn gespecialiseerde ontwikkelteams voor de Java en Vormgeving aanwezig.
Daarnaast kan er ook een beroep gedaan moeten worden op andere ICT expertise binnen of buiten het
CAK.

In het geval dat een backlog item werkzaamheden voor buiten het primaire ontwikkelteam bevat, dan
zal het primaire ontwikkelteam acteren als hoofdaannemer. Het team is daarmee verantwoordelijk voor
het beleggen, monitoren en accepteren van de werkzaamheden buiten het team. De werkzaamheden
buiten het team worden uitgevoerd door onderaannemers.

2.9 Meerdere teams voor een opdrachtgever

In voorkomende gevallen kan het zijn dat er zoveel werk is dat een enkel team onvoldoende capaciteit
kan leveren om de werkzaamheden binnen een acceptabele termijn af te ronden. In dit geval worden
twee of meer teams parallel geschakeld.

Classificatie: niet openbaar pagina 8 van 16 413487271.doc

 Handboek

Om te zorgen dat de werkzaamheden in samenhang worden uitgevoerd wordt de opsplitsing van

werkzaamheden gedaan in samenspraak met de scrummasters en de productowner.

Gedurende de sprints wordt dagelijks een ‘Scrum of scrums’ georganiseerd. In dit overleg wordt de
samenhang en afhankelijkheden tussen de teams bewaakt en besproken.
Verantwoordelijkheden
Teamleider Application De teamleider is verantwoordelijk voor het bewaken van de
Development samenwerking over de teams heen.
Scrummasters Elke scrummaster vertegenwoordigt zijn/haar team. Alle
afhankelijkheden en (gedeelde) belemmeringen worden ingebracht.
Resultaten
Afstemming Weggenomen belemmeringen voor het realisatieproces van alle
teams.

2.9.1 Tools
Tool Inzet
Jira + Greenhopper Alle userstories worden met Greenhopper
toegekend aan een sprint. Tevens worden de
stories binnen jira/Greenhopper afgemeld
wanneer deze gereed zijn.
Scrumboard Elk team maakt gebruik van een scrumboard om
de status van de werkzaamheden te volgen en te
sturen. Een scrumboard heeft typisch de volgende
onderdelen:
 TODO
 In Progress
 To Verify
 Done
 Impediments
Burndownchart De burndownchart geeft de voortgang van de
sprint visueel weer (Zie bijlage 4-sprintxx.xls).
Checklist SCRUM De scrumchecklist kan gebruikt worden om het
SCRUM team scherp en ‘des SCRUMS’ te
houden of te brengen. (zie bijlage 5-Checklist
SCRUM)

Classificatie: niet openbaar pagina 9 van 16 413487271.doc

 Handboek

2.10 Opleveren
Opleveren is tweeledig. Eerst vindt een oplevering vanuit AD plaats aan de productowner. Dit is geen
fysieke oplevering op een systeem. De fysieke oplevering vindt plaats bij de deployment, waarvoor de
systeemeigenaar eindverantwoordelijk is.

2.10.1 Acceptatie
Na een positieve vrijgave vanuit de regressietest zijn de sprintwerkzaamheden voor het ontwikkelteam
afgerond. Het afgeronde product is nu overgedragen aan de productowner.

De productowner besluit wat er met het afgeronde product zal gaan gebeuren. Er kan besloten worden
tot een gebruikerstest of het direct laten deployen op de productie omgeving.

Indien gekozen wordt voor een gebruikerstest en hieruit bevindingen ontstaan, dan zal de productowner
moeten bepalen of dit invloed heeft op de dan lopende sprint, of dat hij ervoor kiest de bevindingen in
een later stadium op te laten pakken. De keus om met bevindingen toch te deployen op productie ligt
ook bij de product owner.

Verantwoordelijkheden
Product owner De productowner is verantwoordelijk voor het accepteren of
afwijzen van de opgeleverde producten.
Gebruikers Gebruikers kunnen in deze fase de opgeleverde producten testen
om de product owner te helpen bij het vormen van een oordeel.
Resultaten
Vrijgave voor in Op basis van gebruikerstest en wel of niet accepteren wordt
productiename en bepaald of het product door kan voor deployment of nog dient te
eventueel product worden aangepast.
backlog items

2.10.2 Deployment
De laatste stap in het voortbrengingsproces is de oplevering van de gerealiseerde producten op de
productie omgeving(en).

De fysieke oplevering wordt uitgevoerd door de afdeling Applicatie Beheer.

Verantwoordelijkheden
Product owner Opdrachtgever voor het uitvoeren van een oplevering op de
productiesystemen
Applicatie Beheer Brengt de sprint producten naar productieomgevingen.
Resultaten
Voltooide oplevering Alle producten die zijn gerealiseerd in een sprint zijn opgeleverd in
de productieomgeving(en).

2.10.3 Tools
Tool Inzet
Jenkins Jenkins wordt gebruikt voor het geautomatiseerd
opleveren van de ontwikkelde software

Classificatie: niet openbaar pagina 10 van 16 413487271.doc

 Handboek

3 Bijlagen
1 Definition of Ready
2 Definition of Done
3 Scrum Guide – NL
4 Burndownchart_sprintxx.xls
5 Checklist SCRUM

Classificatie: niet openbaar pagina 11 van 16 413487271.doc

 Handboek

1 Definition of Ready
De userstory is verwoord als “Als … wil ik … zodat …”, waarbij
 Als … => Voor welke uitvoerende is de userstory belangrijk
 Wil ik … => Wat wil de uitvoerende kunnen doen
 Zodat …=> Waarom wil de uitvoerende dit doen

Onderstaande zaken dienen duidelijk te zijn (geworden) voor de sprintplanning:

Beschrijving huidige situatie

Context waarin het probleem speelt
Achtergrond informatie
Scherm print of schermschets met probleem (igv probleemmelding)
Uitvoerder bekend

Gewenste / verwachte situatie

Doel, reden voor de gewenste aanpassing
Positieve probleemomschrijving (dus wat zou het moeten doen)
Beschrijving van de gegevens relevant voor de aanpassing
Functionele taken benoemd
Functionele servicebeschrijving
Screenshots / schets voor gewenste situatie
Schermflow
Procesflow
Autorisatie matrix
Relatie e/o afhankelijkheden met andere userstories
Relatie e/o afhankelijkheden met andere applicaties

Acceptatiecriteria
Functioneel
Non-functionals ( quint model)

Randvoorwaarden:
De userstory mag geen (grote) vragen meer oproepen
Er is geen twijfel bij de PO over inhoud e/o prio
De userstory bevat geen aannames, maar is gebaseerd op feitelijkheden

 Bovenstaande lijst is nadrukkelijk geen checklist, die voor elke userstory uitgewerkt en vastgelegd
moet zijn. Het doel van de lijst is om het team te helpen bij het beoordelen of zij voldoende informatie
heeft om de userstory te kunnen realiseren.

Classificatie: niet openbaar pagina 12 van 16 413487271.doc

 Handboek

2 Definition of Done

Een sprint is gereed als voor de sprint in zijn geheel en/of voor alle “done” userstories onderstaande zaken zijn
gerealiseerd.

Sprint producten
 Getest werkende software (bij software wijziging), waarbij
o Nieuwe code voldoet aan de richtlijnen en standaarden van het CAK (deze zijn te vinden op de QA
website)
o Alle code is ingecheckt in versiebeheer en voorzien van label
o Software is geplaatst in de release directory voor de sprint
o Debughandlers zijn verwijderd

 Vrijgave advies
o Functionele en technische tests zijn uitgevoerd en OK (conform mastertestplan)
o De opmerkingen vanuit de QA steekproeven zijn verwerkt
o Er is een technisch inhoudelijke review uitgevoerd door middel van een collegiale review
o Het team geeft een positief vrijgave advies

 Systeemdocumentatie
o Nieuwe code is gedocumenteerd conform de richtlijnen en standaarden van het CAK

 Opleverformulier
o Instructies voor het opleveren van de softwareproducten
o Inzicht in afhankelijkheden tussen softwareproducten van de sprint met andere softwareproducten
– xslt, java en Oracle Finance

 Overdracht
o Informatie ter borging van de uitgevoerde aanpassingen is overgedragen aan het project “onze
ICT”
o Alle relevante informatie voor het aanpassen van de regressietestscripts, zodat deze dekkend blijft,
is overgedragen aan het regressietestteam

 Bovenstaande lijst is nadrukkelijk wel een checklist, die voor elke spint afgevinkt moet zijn.

In productie name
 Regressietest
De regressietest is geen integraal onderdeel van de Sprint. Het opleveren van de sprint naar productie
is wel gekoppeld aan een positieve uitslag van de regressietest. De regressietest maakt na-ijlend op
de sprint onderdeel uit van de sprint.
Bij een negatief vrijgaveadvies n.a.v. de regressietest betekent dit dat de sprint niet (direct) opgeleverd
wordt naar productie en de opgetreden fouten worden gerepareerd in de dan lopende sprint of (bij
uitzondering) als “spoedpatch” op de betreffende sprint.

Classificatie: niet openbaar pagina 13 van 16 413487271.doc

 Handboek

3 Scrum Guide – NL
http://www.scrum.org/Scrum-Guides

Classificatie: niet openbaar pagina 14 van 16 413487271.doc

 Handboek

4 Burndownchart_sprintxx.xls

Burndownchart_sprin
txx.xls

De burndownchart maakt een grafiek van taken of uren op het SCRUMboard. Per dag worden voor de
onderstaande categorieën het aantal geeltjes of uren (keuze aan team) vastgelegd:
 Todo
 In Progress
 To Verify
 Done
 Impediments (wordt niet in een grafiek getoond)

In de burndownchart worden de volgende lijnen zichtbaar:

Naam Omschrijving
% Ideal: Dit is de ideale curve. Elke dag wordt continu evenveel werk verricht, wat er toe lijdt dat
de werkzaamheden in een recht aflopende lijn worden afgerond.
% Done: Dit is de lijn gebaseerd op de verhouding ‘gereed’ vs ‘niet gereed’. Deze lijn geeft de
werkelijk afgeronde werkzaamheden weer.
% Todo: Dit is de lijn gebaseerd op de verhouding ‘niet in behandeling’ vs ‘gereed op in
behandeling’. Deze lijn geeft alles weer wat al is opgepakt of afgerond. Deze lijn loopt
op de werkelijkheid van %done vooruit en is bedoeld als ‘vooruitzicht’
Trend Done Dit is de trenslijn gebaseerd op %Done. Op basis van deze lijn kan bepaald worden of
de sprint naar verwachting wel of niet binnen de gestelde termijn wordt afgerond.

Classificatie: niet openbaar pagina 15 van 16 413487271.doc

 Handboek

5 Checklist SCRUM

scrum-checklist.pdf

Classificatie: niet openbaar pagina 16 van 16 413487271.doc