From 517112c96c0183d3962438a857314d6c6830333a Mon Sep 17 00:00:00 2001
From: JanC <108794854+janc-pxl@users.noreply.github.com>
Date: Wed, 11 Sep 2024 16:29:10 +0200
Subject: [PATCH 01/34] PUSH NOTE : 004 Kwaliteitsmanagement.md
---
content/004 Kwaliteitsmanagement.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/004 Kwaliteitsmanagement.md b/content/004 Kwaliteitsmanagement.md
index 4ce48c91..dc37b8d8 100644
--- a/content/004 Kwaliteitsmanagement.md
+++ b/content/004 Kwaliteitsmanagement.md
@@ -54,7 +54,7 @@ Door te focussen op kwaliteit en het implementeren van kwaliteitscontroles, kunn
Belangrijk voor het managen van kwaliteit, ook volgens het PRINCE2-model, is het aanmoedigen van een cultuur van continue verbetering. Door feedback te verzamelen over de kwaliteit (Beheren van kwaliteit) van producten en processen, kunnen projectteams hun huidige werkwijzen aanpassen en verbeteren voor toekomstige projecten. Kortom, kwaliteit is niet alleen een doel op zich, maar ook een middel om het succes van projecten te waarborgen, de risico's te beheersen en de tevredenheid van belanghebbenden te vergroten.
-Binnen projectwerking dienen eerst de doelen worden bepaald om aan klantverwachtingen te voldoen. ISO-standaarden bieden een raamwerk voor consistentie en verbetering en *metrics* zoals KSF (kritieke succesfactoren) en KPI's (kritieke prestatie-indicatoren) helpen bij het meten van prestaties en het sturen van verbeteringen.
+Binnen projectwerking dienen eerst de doelen worden bepaald om aan klantverwachtingen te voldoen. ISO-standaarden bieden een raamwerk voor consistentie en verbetering en *metrics* zoals [[004 Kwaliteitsmanagement#Kritische Succesfactoren (KSF'en) en Kritische Prestatie-Indicatoren (KPI's)|KSF (kritieke succesfactoren) en KPI's (kritieke prestatie-indicatoren)]] helpen bij het meten van prestaties en het sturen van verbeteringen.
## Het belang van goede kwaliteitsdoelen
From c54811dd6c2b5265b2442c76e79eda4e74890714 Mon Sep 17 00:00:00 2001
From: JanC <108794854+janc-pxl@users.noreply.github.com>
Date: Wed, 11 Sep 2024 16:29:11 +0200
Subject: [PATCH 02/34] PUSH NOTE : @wikipediakwaliteitsmanagement_2020.md
From 2a63095ceb0018b6fa83d919bff95c43554af095 Mon Sep 17 00:00:00 2001
From: JanC <108794854+janc-pxl@users.noreply.github.com>
Date: Wed, 11 Sep 2024 16:29:12 +0200
Subject: [PATCH 03/34] PUSH NOTE : @hogeschoolpxl_2024.md
---
content/References/@hogeschoolpxl_2024.md | 52 +++++++++++++++++++++++
1 file changed, 52 insertions(+)
create mode 100644 content/References/@hogeschoolpxl_2024.md
diff --git a/content/References/@hogeschoolpxl_2024.md b/content/References/@hogeschoolpxl_2024.md
new file mode 100644
index 00000000..025d8bb5
--- /dev/null
+++ b/content/References/@hogeschoolpxl_2024.md
@@ -0,0 +1,52 @@
+---
+share: true
+category: References
+title: Kwaliteitszorg
+citekey: hogeschoolpxl_2024
+type: literaturenote
+tags:
+summary: ""
+year: "2024"
+url: https://www.pxl.be/Pub/Over-PXL/Kwaliteitszorg.html
+authors: " Hogeschool PXL, "
+---
+
+> [!Cite]
+> Hogeschool PXL. (2024). _Kwaliteitszorg_. [https://www.pxl.be/Pub/Over-PXL/Kwaliteitszorg.html](https://www.pxl.be/Pub/Over-PXL/Kwaliteitszorg.html)
+
+
+---
+
+# Metadata
+
+>[!Properties]
+> **FirstAuthor** Hogeschool PXL,
+~
+> **Title** Kwaliteitszorg
+> **Year** 2024
+> **Citekey** hogeschoolpxl_2024
+> **itemType** webpage
+
+> [!LINK]
+>
+
+> [!Abstract]
+>.
+>
+# Notes
+
+>>
+
+
+# Annotations
+_annotations in the paper_.
+### Highlights
+
+
+
+### Notes
+
+
+
+### Images
+
From 54cfd6b5bb23642dad92426ee58434cd4c786e0c Mon Sep 17 00:00:00 2001
From: JanC <108794854+janc-pxl@users.noreply.github.com>
Date: Wed, 11 Sep 2024 16:29:13 +0200
Subject: [PATCH 04/34] PUSH NOTE : @governmentofwesternaustralia_2017.md
From f333981f27c0bf2ffb2fc50dddb0a49adff5e0a0 Mon Sep 17 00:00:00 2001
From: JanC <108794854+janc-pxl@users.noreply.github.com>
Date: Wed, 11 Sep 2024 16:29:14 +0200
Subject: [PATCH 05/34] PUSH NOTE : @cspo_2021.md
From 94adef34c430263489f66346140b51568d018526 Mon Sep 17 00:00:00 2001
From: JanC <108794854+janc-pxl@users.noreply.github.com>
Date: Wed, 11 Sep 2024 16:29:15 +0200
Subject: [PATCH 06/34] PUSH NOTE : @sickipedia_2021.md
From 34d52dd19a6838e9d5ec62a63fa24f2d74a2a269 Mon Sep 17 00:00:00 2001
From: JanC <108794854+janc-pxl@users.noreply.github.com>
Date: Wed, 11 Sep 2024 16:29:16 +0200
Subject: [PATCH 07/34] PUSH NOTE : @stefanowicz_2024.md
From 6059e7a392326a5eaa0876f6034de25979193f52 Mon Sep 17 00:00:00 2001
From: JanC <108794854+janc-pxl@users.noreply.github.com>
Date: Wed, 11 Sep 2024 16:29:17 +0200
Subject: [PATCH 08/34] PUSH NOTE : @beljaars_2020.md
From 637f47104207966bf92d9319a762df2745f501f0 Mon Sep 17 00:00:00 2001
From: JanC <108794854+janc-pxl@users.noreply.github.com>
Date: Wed, 11 Sep 2024 16:29:18 +0200
Subject: [PATCH 09/34] PUSH NOTE : 007 Agile Projectmanagement.md
---
content/007 Agile Projectmanagement.md | 943 +++++++++++++++++++++++++
1 file changed, 943 insertions(+)
create mode 100644 content/007 Agile Projectmanagement.md
diff --git a/content/007 Agile Projectmanagement.md b/content/007 Agile Projectmanagement.md
new file mode 100644
index 00000000..0edd0717
--- /dev/null
+++ b/content/007 Agile Projectmanagement.md
@@ -0,0 +1,943 @@
+---
+share: true
+title: 007 Agile Projectmanagement
+category: content
+order: 7
+---
+> [!INFO] Projectmanagement © Hogeschool PXL
+>
+> **OLOD:** 42TIN1250 Projectmanagement
+> **Opleiding:** Professionele bachelor in de Toegepaste informatica
+> **Departement:** [PXL-Digital](https://www.pxl.be/digital)
+> **Lectoren:** [Lowie Vangaal](https://www.linkedin.com/in/lowievangaal/), [Jan Castermans](https://www.linkedin.com/in/jancastermans/)
+
+
+
+
+
+## Wat betekent Agile?
+
+
+
+**Agile** betekent letterlijk *"de behendigheid om snel en makkelijk te bewegen"*.
+In projectmanagement is Agile een methodiek die populair is in de computer industrie, maar het wordt veelvuldig in financiële dienstverlening, marketing, industrie, retail en talloze andere branches toegepast.
+
+Een *"methodiek"* is eenvoudigweg een manier om iets uit te voeren. Het bestaat uit de methodes, technieken en de aanpak om iets daadwerkelijk af te krijgen. In projectmanagement is Agile is een van de meest gebruikte methodieken.
+
+Agile begrijp je het best door te kijken hoe het verschilt van de eerder traditionele manieren waarop je projectmanagement uitvoert.
+
+Traditioneel projectmanagement is getypeerd door een lineaire aanpak waar achtereenvolgens sommige of alle van de volgende stappen zien:
+
+- Initiatie (opstarten van het project)
+- Planning
+- Uitvoering
+- Monitoring
+- Afronding
+
+Agile projectmanagement, voor het eerst gebruikt in de late jaren 80, is gekenmerkt door een **niet-lineaire aanpak**. Waar vroeger requirements en oplossingen al in de "Planning" stap afgehandeld werden, evolueren die nu mee doorheen het proces, door samenwerking tussen zelf-organiserende, cross-functionele teams.
+
+De uitvoering van projectwerk gebeurt voortdurend doorheen de levensduur van het project. Agile methoden staan voor **adaptieve planning**, **evolutionaire ontwikkeling** en **continue verbetering**. We zien aanpasbare planningen, we ontwikkelen op een geleidelijke manier en we omarmen continuous improvement.
+
+*Agile moedigt een snelle en flexibele reactie op verandering aan.*
+
+Het spitst zich toe op teamwerk en op een 1-op-1 afhandelen van producteigenschappen. Men gaat 1 eigenschap volledig afwerken voordat naar een volgende eigenschap wordt overgegaan.
+
+> [!caption]
+> 
+> Afbeelding: De enige zekerheid in een project is dat alles onzeker is
+
+
+> [!abstract] Samengevat
+> Agile is een manier van projectmanagement die zich toespitst op het verdelen van taken in korte werkfases, met veelvuldige reviews (controles) van het project en mogelijke aanpassingen tijdens het uitvoeren. Een Agile aanpak is flexibel en minder strak dan sommige andere manieren van projectmanagement.
+[[./References/@stanley.etal_2020|@stanley.etal_2020]]
+
+## Incrementele ontwikkeling
+
+Een van de eigenschappen van Agile is dat het **incrementeel** is.
+
+> [!note] DEFINITIE: Increment
+> Een Increment is een kleine stap. **Incrementeel** slaat op het voorwaarts bewegen in fasen.
+
+> [!caption]
+> 
+> Afbeelding: incrementele ontwikkeling [[./References/@martin_2020|@martin_2020]]
+
+Incrementele ontwikkeling is een praktijk waar een product stap voor stap gedesignd, gedeployd en getest wordt, totdat het project afgerond wordt. Telkens wordt er een klein beetje meer toegevoegd. Elke stap bouwt verder op de vorige door extra functionaliteiten toe te voegen.
+
+## Iteratieve ontwikkeling
+
+Een andere eigenschap van Agile is dat het iteratief is.
+
+> [!note] DEFINITIE: Iteratief
+> **Iteratief** betekent dat we het herhaald gaan uitvoeren.
+
+Iteratieve ontwikkeling slaat op de ontwikkeling van producten door herhaalde cyclussen. Elk van deze cyclussen voltooit een of andere minimum bruikbaar product *(vert. Engels: minimum viable product)*.
+
+> [!caption]
+> 
+> Afbeelding: iteratieve ontwikkeling
+
+ [^iteratieveontwikkeling]
+
+Bijvoorbeeld:
+
+- 1e iteratie: Maak een simpele homepagina.
+- 2e iteratie: Voeg de mogelijkheid voor een gebruiker toe om een account te maken en in te loggen.
+- 3e iteratie: Voeg de mogelijkheid toe om je wachtwoord te veranderen.
+- 4e iteratie: Voeg een pagina toe die account informatie toont.
+- enz.
+
+Op het eind van elke cyclus is er een afgewerkt product beschikbaar en kan men het product gebruiken.
+
+[^iteratieveontwikkeling]: By Planbox - Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=19543504
+
+## Daily Standups
+
+
+[[./References/@vanderwardt_2017|@vanderwardt_2017]]
+
+De dagelijkse meetings voor de werknemers die aan een project samenwerken noemen we de "Daily Standups". De bedoeling is dat deze maar 5 tot 15 minuten duren. Gebruikelijk staan alle aanwezigen recht. Dit heeft als doel de deelnemers aan te moedigen de vergadering niet nodeloos te rekken. De duurtijd van 15 minuten is een maximum!
+
+> [!note] DEFINITIE: Daily Standup
+> **Daily Standup:** Een dagelijkse meeting van maximum 15 minuten waar elke deelnemer de groep de antwoorden op de volgende 3 vragen verteld:
+> 1. Wat heb ik gisteren bereikt?
+> 2. Wat ga ik vandaag doen?
+>3. Welke mogelijke obstakels belemmeren mijn vooruitgang?
+
+Daily Standups helpen te verzekeren dat mogelijke belemmeringen (zie het stuk over [[007 Agile Projectmanagement#Impediment|Impediment]]) om je werk af te ronden snel geïdentificeerd en vlot weggewerkt raken.
+
+## Product Backlog
+
+Je hebt zeker al het woord 'backlog' horen vallen wanneer het gaat over achterstallig werk, of over werk dat over tijd is. Bijvoorbeeld als je al een maand lang je mails niet meer beantwoord hebt, zou je een backlog van e-mails hebben.
+
+In Agile definieer je een backlog als volgt:
+
+> [!note] DEFINITIE: Product Backlog
+> **Product Backlog:** het openstaande werk. Elke taak die nog veronderstelt wordt te gebeuren, beschouwen we als backlog. Het slaat op het aankomend werk dat nog niet aan een persoon toegewezen is of waarvan de afwerkingsdatum nog niet is vastgelegd.
+
+Als je, bijvoorbeeld, software aan het schrijven bent waarmee je de leden, locaties en rooster van een jeugdbeweging wil vastleggen, zou je wat je moet doen om deze functionaliteit werkelijk te bouwen, opsplitsen in verscheidene individuele taken. Deze lijst is je Product Backlog. Telkens je een taak afgewerkt hebt, zal die verdwijnen van de backlog.
+
+## Sprints
+
+
+[[./References/@visual-paradigm_2022|@visual-paradigm_2022]]
+
+Sprints zijn de hartslag van Agile, waar ideeën worden omgezet in waarde.
+
+Een **Sprint** is een vaste periode (meestal 1, 2 of 4 weken) waarin een specifieke hoeveelheid werk wordt uitgevoerd. Zodra een Sprint eindigt, begint er meteen een nieuwe.
+
+Elke Sprint start met vergaderingen waarin taken verdeeld worden, en eindigt met een review, waarin het uitgevoerde werk wordt bekeken en besproken.
+
+In Agile worden projecten verdeeld in Sprints. Elke dag tijdens een Sprint zijn er Daily Standups om de voortgang te bespreken.
+
+Het [[007 Agile Projectmanagement#Sprint Doel|Sprint Doel]] is de centrale focus en het einddoel van een Sprint. Dit wordt ook wel het 'thema' van de Sprint genoemd.
+
+Nu dat je een basisbegrip van Agile projectmanagement hebt, kijken we naar de populairste tak (subcategorie) van Agile.
+
+## Scrum
+
+ [^rugbyscrum]
+
+**Scrum** is een van de mogelijke uitvoeringen van Agile.
+
+De term 'Scrum' komt van een uitdrukking uit de rugbysport waar de teamleden elkaars armen laten ineengrijpen en zo voorwaarts richting de tegenstander drukken.
+
+In de technologiewereld is Scrum een manier van projectmanagement die bestaat uit:
+
+- strak gecoördineerd teamwerk.
+- een sterke organisatie.
+- het afwerken van project volgens de vraag van de klant.
+
+Het gros van de huidige development projecten gebruikt Scrum. Ondanks de verzameling termen en technieken gebruikt in Scrum, draait het allemaal rond teamwerk, het samenspel tussen de leden van het team.
+
+
+
+Hoewel Scrum oorspronkelijk is bedacht voor softwareontwikkeling, wordt het toegepast in vele andere sectoren, zoals gezondheidszorg, marketing, rechtshandhaving, productontwikkeling en de publieke sector op alle niveaus.
+
+Waar we Agile beschouwen als een methodologie, spreken we bij Scrum over een raamwerk *(Vert. Engels: framework)*. De reden dat we dat vermelden is zodat je weet dat er technisch een verschil is tussen beide termen.
+
+> [!info]
+> Een **methodologie** is een verzameling regels, methoden en gereedschappen die men kan gebruiken om een bepaald doel te bereiken.
+> Spreken we over een **raamwerk**, dan denken we aan een "lossere", meer flexibele structuur waar we toelaten andere gereedschappen te gebruiken.
+
+
+> [!note] DEFINITIE: Scrum
+> **Scrum (n):** een eenvoudig raamwerk voor complexe productontwikkeling (1); een eenvoudig raamwerk om complexe uitdagingen te adresseren (2); een eenvoudig raamwerk dat mensen helpt om waarde te genereren uit complexe uitdagingen (3). [[./References/@verheyen_2022|@verheyen_2022]]
+
+Alle termen en concepten die we tot nu toe bespraken voor Agile, passen we toe in Scrum, zoals:
+- **Sprints** (vaste periodes van 1 week, 2 weken, enz.)
+- **Backlogs** (overzichten van openstaand werk)
+- **Daily Standups** (dagelijkse bijeenkomsten van de Developers)
+
+In Scrum gebruikt men deze terminologie zoals hierboven omschreven, maar toegepast door het woord 'Scrum' er aan vast te hangen – zoals *"Scrum Sprints"* of *"Daily Scrum"*. De betekenis is gelijk aan die van Agile, **Scrum is Agile!**
+
+Een goede manier om de relatie tussen Scrum en Agile te bekijken is het volgende plaatje.
+
+> [!caption]
+> 
+> Afbeelding: relatie tussen scrum en agile
+
+Of, om het met een analogie te bekijken.
+
+> [!caption]
+> 
+> Afbeelding: relatie tussen sport, basketbal en NBA [[./References/@stanley.etal_2020|@stanley.etal_2020]]
+
+In dit voorbeeld bekijk je “sports” als projectmanagement, “basketbal” als Agile en “NBA” (de populairste uitvoering van basketbal) is Scrum.
+
+> [!note] DEFINITIE: Sprint (in Scrum)
+> **Sprint:** een event dat als een zogenaamd ‘container event’ de overige Scrum Events omvat, met een time-box van niet meer dan vier weken. De overige events in Scrum zijn: Sprint Planning, Daily Scrum, Sprint Review en Sprint Retrospective.[[./References/@verheyen_2022|@verheyen_2022]]
+
+
+### Empirische procescontrole
+
+> [!caption]
+> 
+> Afbeelding: scrum en empirisme [[./References/@zentaoteam_2022a|@zentaoteam_2022a]]
+
+Scrum is gebaseerd op de filosofie van het empirisme.
+
+Binnen het empirisme gaat men ervan uit dat *"kennis alleen kan voortkomen uit ervaring"*. Kennis is gestoeld op (objectieve) observaties en niet op ideeën. Er is een verschil tussen ‘denken’ en ‘weten’. Met andere woorden: je kunt denken dat je weet wat de klant wenst, maar daarmee weet je het nog niet zeker.
+
+Deze drie pilaren ondersteunen de ontwikkeling van elke empirisch proces: **transparantie**, **inspectie** en **aanpassing**. Maar wat wil dat nu in mensentaal zeggen?
+
+- **Transparantie**: Dit betekent de feiten voorstellen zoals ze zijn. Elke betrokken persoon – de klant, de CEO, individuele bijdragers (de Developer) – is goed te controleren in de dagelijkse omgang met anderen. Iedereen vertrouwt de ander, en heeft de moed om elkaar op de hoogte te houden van zowel goed als slecht nieuws. Iedereen streeft naar en werkt samen voor het gemeenschappelijk bedrijfsdoel, en geen enkel persoon heeft een verborgen agenda!
+
+- **Inspectie**: Men kan het product, de processen, menselijk aspecten, praktijken en de voortdurende verbeteringen inspecteren. Het team toont aan het einde van elke Sprint, open en doorzichtig, het product aan de klant om hierdoor waardevolle feedback te krijgen. Wanneer de klant de vereisten na inspectie aanpast, gaat het team niet klagen. Het gaat zich net flexibel opstellen en dit zien als een kans om nóg beter samen te werken met de klant, diens vereisten nog duidelijker te zien en de nieuwe veronderstelling uit te testen.
+
+- **Aanpassing**: Aanpassing beschouwen we in deze context als alle voortdurende verbeteringen die we aanbrengen. We zien het als de mogelijkheid aan te passen, kijkend naar de resultaten van de Inspectie. Iedereen in de organisatie moet op geregelde tijdstippen zich de vraag stellen: *"Staan we er beter voor dan gisteren?"*
+[[./References/@doshi_2016|@doshi_2016]]
+
+> [!tip] tip
+> Later, in de [[007 Agile Projectmanagement#Scrum Waarden|Scrum Waarden]], gaan we dieper in op de manier waarop de Empirisch gedachte in Scrum uitgewerkt is.
+> Het kan geen kwaad deze uit te printen, ze op je nachtkastje te leggen, ze af en toe te lezen en een traantje weg te pinken. Beschouw ze als mogelijk de waardevolste lessen die je dankzij Scrum kan leren.
+
+Nu dat je weet wat Scrum is, kijken we naar enkele andere Scrum-gerelateerde processen, rollen en definities.
+
+[^rugbyscrum]: By PierreSelim - Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=17336884
+
+## Product Owner
+
+In Agile en Scrum is de **Product Owner** de persoon die het gezag heeft de belangen van de klant te vertegenwoordigen.
+De Product Owner is altijd beschikbaar voor het projectteam (al is die zelf niet betrokken in het ontwikkelen van het project) en is aanwezig bij het merendeel van de vergaderingen. Een Product Owner is de "baas" *(maar neem dat zeker niet letterlijk, de reden dat het woord tussen quotes staat is niet toevallig)* van het project, maar ze laten de teamleden toe hun eigen doelen te bepalen en zichzelf te managen.
+
+> [!caption]
+> 
+> Afbeelding: De product owner en diens taken [[./References/@userstorymap_2022|@userstorymap_2022]]
+
+Typisch zijn Product Owners de personen die met de klant samenzitten.
+
+Sommige van hun taken omvatten:
+
+- het duidelijk omschrijven van backlog taken
+- verzekeren dat de backlog zichtbaar en duidelijk is voor iedereen
+- verzekeren dat iedereen de prioriteiten kent, en weet wat als volgende taak wordt beschouwd.
+
+Zoals deze taken al tonen, is de Product Owner verantwoordelijk voor de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]].
+
+Het woord "owner" *(vertaling: eigenaar)* verwijst naar verantwoordelijkheid – de Product Owner houdt er zicht op dat het product naar behoren wordt ontwikkeld.
+
+De Product Owner bekijkt projecten vanuit het perspectief van de klant en verzekert dat het werk volgens de visie van de klant wordt uitgevoerd.
+
+> [!note] DEFINITIE: Product Owner
+> **Product Owner:** De Product Owner in Scrum is verantwoordelijk voor het bepalen van wat het team moet bouwen, de taken te prioriteren volgens belangrijkheid en waarde, en te zorgen dat het team altijd duidelijke richtlijnen heeft om het juiste product te ontwikkelen.
+
+### Stakeholders
+
+#### Wat is een stakeholder?
+
+Stakeholders beschouwen we als alle partijen die interesse hebben in een op te leveren product of project. Ze beïnvloeden het project of het project beïnvloedt hen, ze hebben (in)direct invloed en interesse in het Scrum project.
+Door deze afhankelijkheid zijn ze in staat het project te maken of te breken. Aan de ene kant beschouwen we als stakeholders de mensen die dicht bij je Scrum project staan, zoals je belangrijkste klanten, managers en interne opdrachtgevers. Aan de andere kant zien we ze als de personen die verder van je af staan, zoals de CEO of de Board of Directors.
+
+> [!note] DEFINITIE: Stakeholder
+> **Stakeholder:** een persoon van buiten het Scrum Team met een specifiek belang in het product of kennis ervan die noodzakelijk is voor de verdere ontwikkeling van het product. [[./References/@verheyen_2022|@verheyen_2022]]
+
+#### Stakeholders identificeren
+
+> [!caption]
+> 
+> Afbeelding: identificeren van stakeholders
+
+Het identificeren van stakeholders kan je als [[007 Agile Projectmanagement#Product Owner|Product Owner]] alleen doen, maar je kan hierbij evengoed de hulp van de rest van het Scrum Team vragen. We kennen drie categorieën: interne, externe en interface stakeholders:
+
+1. **Interne stakeholders**: deze willen vooral dat het project winstgevend en/of efficiënt verloopt. Bijvoorbeeld de afdelingen binnen de organisatie, zoals logistiek, marketing, finance, HR.
+
+2. **Externe stakeholders**: deze zitten op behoefte-invulling van het project en hebben een emotioneel belang. Het betreft bijvoorbeeld de eindgebruiker, de consument, de betalende klant.
+
+3. **Interface stakeholders**: deze hebben mogelijk invloed door wet- en regelgeving, bijvoorbeeld de overheid, maatschappij, onderwijs.
+[[./References/@vanlier_2018|@vanlier_2018]]
+
+## Scrum Master
+[[./References/@qframe_2021|@qframe_2021]]
+
+De Scrum Master is, in tegenstelling tot de [[007 Agile Projectmanagement#Product Owner|Product Owner]], werkelijk betrokken met de softwareontwikkeling. Het is de persoon die de groepsactiviteiten coördineert en laat functioneren. De Scrum Master is er, op het terrein, werk uitvoerend en de mede-teamgenoten helpend. De rol van Scrum Master is niet altijd door dezelfde persoon voor lange tijd opgenomen. Sommige teams hebben voorzien dat deze rol een wisselrol is, zodat elk teamlid dit een bepaalde periode kan uitvoeren.
+
+Sommige van de taken van deze rol omvatten:
+- het verwijderen van obstakels *(vert. Engels: [[007 Agile Projectmanagement#Impediment|Impediment]]s)* tijdens ontwikkelingen.
+- het verzekeren dat de ontwikkelomgeving opgezet is zodat het men het project kan afmaken.
+- de teamleden opleiden in [[007 Agile Projectmanagement#Scrum|Scrum]] en er op toezien dat de uitvoering van de processen correct loopt.
+- een goede relatie onderhouden tussen de ontwikkelaars en de [[007 Agile Projectmanagement#Product Owner|Product Owner]], evenals met anderen buiten het team.
+- de [[007 Agile Projectmanagement#De Developers|Developers]] behoeden voor verstoringen van buitenaf en andere afleidingen.
+
+> [!note] DEFINITIE: Scrum Master
+> **Scrum Master:** de persoon die aansprakelijk is voor een correct begrip en effectief gebruik van Scrum door Scrum Teams en hun bredere omgeving door technieken als coaching, facilitering, lesgeven en stilzwijgende observatie. [[./References/@verheyen_2022|@verheyen_2022]]
+
+De term *"master"* kenmerkt in deze context niet iemand die anderen voor zich laat werken. Het is eerder te verstaan als *"een specialist van een bepaald onderwerp"*. Waar we de Scrum Master hebben als iemand die het beste (of zeker een sterk) begrip van Scrum heeft, vergeleken met de rest van de mensen betrokken bij het project. Men beschouwt hen als de *'masters van het Scrum raamwerk'*.
+
+### Impediment
+
+
+
+Een **impediment** *(synoniem: belemmering, hindernis of obstakel)* is iets wat vooruitgang blokkeert of vertraagd.
+
+In een letterlijke betekenis kun je een omgevallen boom die een straat blokkeert een "impediment" noemen.
+
+In Scrum is een impediment eender wat dat het team tegenhoudt hun volledige potentieel te gebruiken.
+
+> [!note] DEFINITIE: Impediment
+> **Impediment:** elke hindernis of obstakel dat het ontwikkelwerk blokkeert of vertraagt, maar niet kan weggenomen worden via zelfsturing. De verwijdering ervan is onderdeel van de aansprakelijkheid van de Scrum Master. [[./References/@verheyen_2022|@verheyen_2022]].
+
+Dit omvat problemen die een project tegenhouden het op tijd en tegen het juiste budget te laten beëindigen. Het is de taak van de [[007 Agile Projectmanagement#Scrum Master|Scrum Master]] deze impediments te behandelen of te verwijderen.
+
+Voorbeelden van impediments: zieke teamleden, ontbrekende resources, afwezigheid van management-support, een te koude werkruimte, conflicten tussen teamleden, problemen met leveranciers, gebrekkige technische kennis.
+
+> [!important] Belangrijk
+> Bij vraag 3 van de [[007 Agile Projectmanagement#Daily Standups|Daily Scrums]] (*"Welke mogelijke obstakels belemmeren mijn vooruitgang?"*) is het de morele verplichting elk nieuwe impediment te signaleren. Dit laat toe blokkades zo snel mogelijk op te lossen.
+
+## De Developers
+
+
+
+De Developers *(synoniem: Ontwikkelingsteam, Ontwikkelteam, of Development team)* bestaat uit professionals die werken aan de taken die horen bij de ontwikkeling van het product. Deze taken bepaalt men voor elke Sprint in overleg met de Product Owner, die de taken selecteert uit de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]]. Aan het eind van de Sprint is het de bedoeling dat de Developers alle taken die geselecteerd waren hebben uitgevoerd.
+
+### Kenmerken van de Developers
+
+De Developers hebben enkele kenmerken:
+
+- Het team is zelforganiserend. Niemand vertelt het team hoe de geselecteerde [[007 Agile Projectmanagement#Product Backlog item|Product Backlog item]]s uit te voeren, zelfs de [[007 Agile Projectmanagement#Scrum Master|Scrum Master]] niet.
+- Er is een grote mate van persoonlijk leiderschap.
+- Het team is cross-functioneel. De leden van het team bezitten samen minimaal 80% van de vaardigheden om de taken uit te voeren.
+- Het team is één. Het is niet toegestaan subteams te maken; het team blijft altijd bij elkaar.
+- Het team is samen verantwoordelijk. Als iemand binnen het team omwille van benodigde vaardigheden bepaalde taken uitvoert, is het team alsnog gezamenlijk verantwoordelijk voor het eindresultaat.
+
+### Aantal teamleden
+
+Hoeveel leden een team bevat, hangt natuurlijk af van de organisatie en het project. Over het algemeen geldt dat een team moet bestaan uit 3 tot 10 leden. Minder dan drie mensen in het team verkleint de interactie, wat leidt tot lagere productiviteit. Daarnaast mankeert men mogelijk bepaalde vaardigheden in het team, waardoor er tegen problemen wordt aangelopen. Meer dan 10 mensen in het team vereist strakkere coördinatie en zorgt voor hogere complexiteit.
+**De [[007 Agile Projectmanagement#Product Owner|Product Owner]] en de [[007 Agile Projectmanagement#Scrum Master|Scrum Master]] horen niet tot de Developers, behalve als ze taken uit de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]] uitvoeren.**
+[[./References/@scrumguide_2022|@scrumguide_2022]]
+
+Laten we nog de belangrijkste Scrum rollen herhalen om deze nog verder duidelijk te maken.
+
+## De drie Rollen in Scrum
+
+> [!caption]
+> 
+> Afbeelding: de drie rollen in scrum
+
+[^scrumteam]
+
+De drie hoofdrollen in Scrum zijn:
+
+#### Product Owner
+
+Deze persoon is verantwoordelijk voor het uitzetten van het openstaande werk en het voor het prioriteren van dat werk. [[007 Agile Projectmanagement#Product Owner|Product Owner]]s kennen de verwachtingen van het project en nemen een gidsende rol aan naar het team dat het project gaat uitvoeren.
+
+Product Owners blijven betrokken bij het project gedurende de volledige duurtijd. Dit in tegenstelling tot de baas, die in de meeste gevallen alleen betrokken is in het begin, tijdens de initiële planning. De [[007 Agile Projectmanagement#Product Owner|Product Owner]] verzekert dat het product wordt aangepast en geherprioriteerd wanneer nodig.
+
+Ondanks al deze taken gaat de [[007 Agile Projectmanagement#Product Owner|Product Owner]] nooit de activiteiten van de [[007 Agile Projectmanagement#De Developers|Developers]] sturen of controleren - dat wordt afgehandeld door de [[007 Agile Projectmanagement#Scrum Master|Scrum Master]].
+
+#### Scrum Master
+
+Een [[007 Agile Projectmanagement#Scrum Master|Scrum Master]] heeft twee hoofdtaken:
+
+- Ze beschermen de Developers en verzekeren dat iedereen zich kan focussen op het werk, met minimale afleiding. Dit omvat het isoleren en afhandelen van mogelijke '[[007 Agile Projectmanagement#Impediment|Impediment]]s' die optreden.
+- Ze beschermen het Scrumproces zelf en verzekeren dat het correct uitgevoerd wordt. Hiervoor moet de Scrum Master een nauwkeurige kennis van Agile en Scrum bezitten. Een belangrijk element hierin is het optreden als zowel trainer als coach voor alle teamleden.
+
+#### De Developers
+
+De personen die de taken uitvoeren.
+
+[[007 Agile Projectmanagement#De Developers|Developers]] voor een softwareproducent bijvoorbeeld, is een team van architecten, testers, ontwikkelaars en designers.
+
+Het team treed samen op om te bepalen hoe ze hun doelen gaan bereiken. De bepaalde features waaraan ze gaan werken zijn gebaseerd op de prioriteiten afgesproken door de [[007 Agile Projectmanagement#Product Owner|Product Owner]]
+
+[^scrumteam]: by Scrum.org - https://www.scrum.org/resources/blog/equality-accountabilities-scrum
+
+Zo, nu dat we project managers, [[007 Agile Projectmanagement#Product Owner|Product Owner]]s en Scrum Masters hebben bekeken, nog de verschillen tussen deze drie functies.
+
+## Terminologie (herhaling)
+
+De termen “[[007 Agile Projectmanagement#Scrum Master|Scrum Master]]”, “projectmanager” en “[[007 Agile Projectmanagement#Product Owner|Product Owner]]” scheppen zo nu en dan verwarring. Ze betekenen allen iets totaal anders.
+
+De **Scrum Master** is een lid van de Developers welke de coördinatie doet van het werk van de collega-teamleden. De Scrum Master verzekert dat Scrum begrepen is en wordt toegepast door iedere persoon betrokken bij het project.
+
+Een **Product Owner** is de persoon die de uiteindelijke autoriteit heeft de klantenbelangen te vertegenwoordigen en ze hebben rechtstreekse klanteninteractie.
+
+De **projectmanager** is de persoon die de totale verantwoordelijkheid voor het volledige project heeft. Technisch gezien is er geen projectmanager-rol in Scrum - de Product Owner en de Scrum Master delen deze taken.
+
+Scrum Master is een Scrum term. Product Owner is een Agile term die tevens in Scrum gebruikt word. En project manager is een algemene term, gebruikt in vele beroepen en industrieën.
+
+## Sprint Planning
+
+Bij de start van elke Sprint, is er een planningssessie binnen het team: de **Sprint Planning**.
+
+
+[[./References/@raghuprasad_2019|@raghuprasad_2019]]
+
+Tijdens de Sprint Planning plannen we de [[007 Agile Projectmanagement#Sprint Backlog|Sprint Backlog]]. Meer bepaald gaat het team dan beslissen welke [[007 Agile Projectmanagement#Product Backlog item|Product Backlog item]]s (PBI's) ze aanpakt tijdens de volgende Sprint. Ze nemen items uit de Product Backlog die ze plaatsen in de [[007 Agile Projectmanagement#Sprint Backlog|Sprint Backlog]]. Hier kiezen ze, naargelang de belangrijkheid en rekening houdend met de capaciteit van het team, de onderwerpen die ze denken af te ronden in 1 Sprint. Belangrijk is hier de capaciteit van het team goed in te schatten. Dat kan door het bekijken van de [[007 Agile Projectmanagement#Velocity|Velocity]] en door rekening te houden met verlofdagen en opleidingen van leden van het team.
+
+> [!note] DEFINITIE: Sprint Planning
+> **Sprint Planning:** het event dat het begin van een Sprint uitmaakt, met een time-box van acht uur of minder. Tijdens dit event bepaalt het Scrum Team welke selectie van de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]] in een Sprint wordt opgenomen en identificeert het Sprint Doel en de ontwikkelactiviteiten ervoor. [[./References/@verheyen_2022|@verheyen_2022]]
+
+Niet alleen de [[007 Agile Projectmanagement#Sprint Backlog|Sprint Backlog]] wordt tijdens de Sprint Planning bepaald, er wordt tevens een duidelijk [[007 Agile Projectmanagement#Sprint Doel|Sprint Doel]] vastgelegd.
+
+> [!caption]
+> 
+> Afbeelding: Product en Sprint Backlog [[./References/@zentaoteam_2022a|@zentaoteam_2022a]]
+
+Sommige teams kiezen bepaalde taken aan bepaalde ontwikkelaars toe te wijzen, maar dit is niet nodig. Het gros van de teams beslist alleen maar over de [[007 Agile Projectmanagement#Sprint Backlog|Sprint Backlog]], en laat de teamleden beslissen wie aan welke taak werkt tijdens de uitvoering van de Sprint.
+
+### User Stories (en Epics)
+
+> [!caption]
+> 
+> Afbeelding: User stories en acceptatiecriteria [[./References/@productplan_2022|@productplan_2022]]
+
+Een **User Story** is een Agile en Scrum werkinstrument dat als doel heeft producten (*"software"*) te beschrijven vanuit het standpunt van een eindgebruiker.
+
+==Herinner je dat we in het begin van deze cursus over Increments spraken? Een User Story is het perfecte voorbeeld van een Increment in Scrum.==
+
+> [!important] User Story
+> User Stories bevatten **het type gebruiker**, **wat ze willen** en **waarom**.
+
+We schrijven ze als volgt:
+
+> [!important] Vorm
+> "**als** (type gebruiker), **wil ik** (een bepaald doel) **zo dat** (een bepaalde reden)"
+
+voorbeeld:
+
+> [!example] Voorbeeld
+> "**Als** een gebruiker, **wil ik** in mijn account kunnen inloggen met een gebruikersnaam en wachtwoord, **zo dat** ik toegang kan krijgen tot mijn account informatie"
+
+Agile en Scrum laten ontwikkelaars werken aan taken beschreven door User Stories.
+
+**Epics**, in Agile en Scrum, verwijzen naar grotere blokken werk (grote taken) die we vervolgens verder verdelen in User Stories (kleinere taken)
+
+Zowel Epics als Stories zijn voorbeelden van [[007 Agile Projectmanagement#Product Backlog item|Product Backlog item]]s (PBIs).
+
+#### Voorbeelden van User Stories in een Product Backlog
+
+| als een | wil ik | zodat |
+| ------------- | -------------------------------------- | -------------------------------------------------------------------- |
+| administrator | een lijst zien van leden en bezoekers | ik de sitebezoeken kan monitoren |
+| administrator | nieuwe categorieen kunnen toevoegen | ik leden kan toelaten interessante content te maken |
+| administrator | nieuwe securitygroepen toevoegen | security levels voldoende zijn |
+| administrator | nieuwe trefwoorden toevoegen | inhoud makkelijk te groeperen en te doorzoeken is |
+| administrator | commentaar kunnen verwijderen | beledegende commentaar kan verwijderd worden |
+| administrator | inhoud kunnen tegenhouden | concurrenten en overtreders geen inhoud kunnen versturen |
+| administrator | wil ik de site stijl kunnen aanpassen | de site future-proof is indien de branding van het bedrijf verandert |
+| lid | mijn wachtwoord veranderen | ik veilig kan blijven |
+| lid | mijn contactgegevens aanpassen | administrators mij kunnen contacteren |
+| lid | mijn email voorkeuren kunnen aanpassen | ik niet gebombardeerd wordt met junk email |
+| lid | inhoud delen op sociale netwerken | ik kan delen wat ik interessant vind |
+| bezoeker | een account aanmaken | ik ledenkorting kan krijgen |
+| bezoeker | kunnen inloggen | ik nieuwe inhoud kan delen |
+| bezoeker | commentaar kunnen invoeren | ik mijn mening kan verkondigen |
+| bezoeker | verbetering voorstellen | ik mijn bijdrage kan leveren aan de bruikbaarheid van de site |
+| bezoeker | administrators contacteren | ik een rechtstreekse vraag kan stellen |
+| bezoeker | de updates van een lid volgen | ik op de hoogte blijf van updates van leden die ik interessant vind |
+| bezoeker | het profiel van een lid zien | ik meer kan weten over een lid |
+
+> [!caption]
+> 
+> Afbeelding: het is belangrijk je User Stories correct te schrijven
+
+#### Acceptatie Criteria
+
+**Acceptatie criteria** geven een duidelijke beschrijving van wat men verstaat onder "done" (gedaan) in de terminologie van User Stories.
+Ze beschrijven de standaarden waartegen iets wordt beoordeeld, de requirements.
+
+> [!example] Voorbeeld
+> User story: **Als** een gebruiker van deze website, **wil ik** dat de plaatjes vergroten wanneer ik er met de muis over beweeg, **zo dat** ik onder de indruk ben van de interactiviteit van de site
+
+> [!example] Voorbeeld
+> Acceptatie criteria: Alle beelden worden 25% groter wanneer men er met de muis over komt.
+
+#### Agile User Stories (Video)
+
+VIDEO
+
+### Product Backlog item
+
+Een **"Product Backlog item"** (PBI, Backlog item of item genoemd) is een eenduidige taak die je moet afronden.
+
+User Stories, Epics, Taken, Bugs of Change Requirements zijn voorbeelden van Product Backlog items.
+
+De [[007 Agile Projectmanagement#Product Owner|Product Owner]] verzamelt en prioriteert de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]] door de dringendste of belangrijkste PBI's bovenaan te plaatsen.
+
+Bijvoorbeeld, wanneer men een website gaat maken van 10 pagina's, kun je elke webpagina als een PBI omschrijven.
+
+### Sprint Doel
+
+Het Sprint Doel (of de Sprint Goal) is een korte zin van een of twee regels die beschrijft wat het Team wil bereiken in deze [[007 Agile Projectmanagement#Sprint|Sprint]]. Deze zin wordt door de [[007 Agile Projectmanagement#Product Owner|Product Owner]] en het Team gezamenlijk opgesteld.
+
+> [!example] Voorbeeld
+> - Implementeer een ‘winkelwagen’ functionaliteit met toevoegen, verwijderen en update mogelijkheid.
+> - Ontwikkel een ‘check out’ mogelijkheid: betalen voor de order, verzending etc.
+
+Het Sprint Doel is handig om [[007 Agile Projectmanagement#Stakeholders|Stakeholders]] op de hoogte te houden. Stakeholders hebben geen behoefte aan alle gedetailleerde items, het doel van de komende Sprint te weten is al genoeg.
+
+> [!note] DEFINITIE: Sprint Doel
+> **Sprint Doel:** een korte omschrijving van de overkoepelende doelstelling van een Sprint. [[./References/@verheyen_2022|@verheyen_2022]]
+
+Het succes van deze Sprint wordt beoordeeld in de [[007 Agile Projectmanagement#Sprint Review|Sprint Review]]. Het opgeleverde wordt vergeleken met het Sprint Doel. In de [[007 Agile Projectmanagement#Sprint Review|Sprint Review]] kijkt men niet naar de specifieke items, maar beoordeeld men of het doel is behaald.
+[[./References/@agile4all_2019|@agile4all_2019]]
+
+### Sprint Backlog
+
+Een **“Sprint Backlog”** is de taak (of de taken) die een team hoopt af te ronden tijdens een bepaalde Sprint.
+
+Een Sprint Backlog is een lijst met User Stories die tijdens een Sprint moeten worden voltooid. Het team schat de User Stories in Storypunten en werkt eraan om ze allemaal af te ronden.
+
+
+> [!note] DEFINITIE: Sprint Backlog
+> **Sprint Backlog:** De Sprint Backlog is samengesteld uit het Sprint Doel (waarom), de set van Product Backlog items geselecteerd voor de Sprint (wat) en een uitvoerbaar plan voor het opleveren van het Increment (hoe)..
+
+#### Verschil tussen Product Backlog en Sprint Backlog
+
+Ten slotte, voor wie het nog niet duidelijk is, hier een overzicht van de verschillen tussen de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]] en de Sprint Backlog
+
+| Product Backlog | Sprint Backlog |
+| ------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| De nodige lijst van alle Product Backlog items zodat het eindproduct kan ontwikkeld worden | De lijst van items, gekozen uit de Product Backlog, die moeten afgewerkt worden om te bekomen dat de Sprint afgerond is |
+| De Product Owner is verantwoordelijk voor het verzamelen van de Product Backlog items en prioriteert en verfijnt ze | Het team is verantwoordelijk voor het maken van de Sprint Backlog en die te verwerken om de Sprint af te ronden |
+| De Product Backlog is bepaald door het volledig doel van het product | De Sprint Backlog is bepaald door het Sprint Doel van een specifieke Sprint |
+| Kan veranderen afhankelijk van de visie van de klant | De Sprint Backlog mag uitzonderlijk, in het geval dat het Sprint Doel dezelfde blijft, veranderen |
+| Alle productkenmerken en storypunten zijn toegewezen aan de individuele User Stories | De Sprint Backlog gedraagt zich als een todo list voor elke Sprint. De Ontwikkelaar verdeelt de User Stories in taken zodat de ingeschatte tijd om ze af te ronden kan berekend worden. |
+| De Product Backlog bestaat zolang het hele product wordt ontwikkeld en moet altijd onderhouden worden | Elke nieuwe Sprint heeft een nieuwe Sprint Backlog, die dan ook eindigt bij het beëindigen van de Sprint |
+
+## Product Backlog Refinement
+
+
+[[./References/@vanrooden_2015|@vanrooden_2015]]
+
+[[./References/@vanrooden_2015a|@vanrooden_2015a]]
+
+Product Backlog Refinement is een meeting gedurende de Sprint waarin we items van de Product Backlog bespreken en verduidelijken. We proberen in te schatten hoeveel [[007 Agile Projectmanagement#Storypunten|Storypunten]] er voor elke PBI ([[007 Agile Projectmanagement#Product Backlog item|Product Backlog item]]) nodig is zijn deze af te ronden en we geven de taken een prioriteit.
+
+Backlog Refinement noemt men "Backlog Grooming" of "Story Time".
+
+> [!note] DEFINITIE: Product Backlog Refinement
+> **Product Backlog refinement:** de regelmatige activiteit om gradueel verfijndere inzichten te creëren in de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]]. [[./References/@verheyen_2022|@verheyen_2022]]
+
+Een belangrijk aspect hierin waarover je zeker moet leren is de inschatting van moeilijkheid een taak af te ronden. De twee gebruikelijkste zijn "T-shirt grootte" en "Fibonacci reeks". Beide methodes duiden aan hoeveel werk er nodig is voor een bepaalde taak.
+
+De "T-shirt grootte" toepassing betreft het toewijzen van een T-shirt maat, welke de moeilijkheid van uitvoering aangeeft, aan elke taak. Gebruikelijk zie je small, medium, large en extra-large.
+
+De "Fibonacci reeks" uitvoering betreft het toewijzen van een nummer, welke de moeilijkheid aangeeft, aan elke taak. Deze waardes komen van de bekende wiskundige reeks nummers, ooit, eeuwen geleden, ontwikkeld door de Italiaanse wiskundige Fibonacci. Ze zijn een reeks nummers, waar elke nummer de som is van de vorige twee nummers:
+
+>[!caption]
+>
+> Afbeelding: de Fibonacci reeks
+
+1, 2, 3, 5, 8, 13, enz.
+
+Hoe hoger het getal, hoe moeilijker de taak is.
+
+Wanneer een bepaalde taak buiten de aanvaardbare range van de T-shirtgrootte of Fibonacci reeks valt, wordt bepaald dat ze de taak best opsplitsen in kleinere, behapbare deeltaken. We bekijken dit verderop in detail bij de tekst over [[007 Agile Projectmanagement#Storypunten|Storypunten]].
+
+## Sprint Review
+
+De Sprint Review is bedoeld als het officiële moment tijdens elke Sprint waarin het Scrum Team aan de [[007 Agile Projectmanagement#Stakeholders|Stakeholders]] het gemaakte (deel)product toont. De Stakeholders geven hun terugkoppeling op het (deel)product dat gedemonstreerd is.
+
+Daarnaast tonen we alleen de [[007 Agile Projectmanagement#User Stories (en Epics)|User Stories]] die daadwerkelijk afraakten tijdens de Sprint. Items die niet (helemaal) klaar raakten tonen we niet. Dit zou een verkeerde indruk geven van de hoeveelheid waarde die opgeleverd is.
+
+Het laatste onderdeel van de Sprint Review is het bespreken van de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]] door de [[007 Agile Projectmanagement#Product Owner|Product Owner]]. Deze neemt de [[007 Agile Projectmanagement#Stakeholders|Stakeholders]] mee in de stand van zaken. Welke items hebben de hoogste prioriteit en gaan we tijdens de volgende Sprint oppakken? Welke nieuwe items bevat de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]]?
+[[./References/@agilescrumgroup_2018|@agilescrumgroup_2018]]
+
+> [!note] DEFINITIE: Sprint Review
+> **Sprint Review:** het event dat het einde van de ontwikkelactiviteiten van een Sprint uitmaakt, met een time-box van vier uur of minder. Tijdens dit event bespreken het Scrum Team en uitgenodigde belanghebbenden de resultaten van de [[007 Agile Projectmanagement#Sprint|Sprint]], de huidige inhoud van de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]] en de voortgang op productniveau. Het doel is om potentieel belangrijk werk voor de nabije, of verdere, toekomst te identificeren. Het resultaat is een bijgewerkte Product Backlog. [[./References/@verheyen_2022|@verheyen_2022]]
+
+## Sprint Retrospective
+
+"Retrospect" (terugblik) betekent het reviseren of bevragen van voorbije gebeurtenissen of tijdsperioden.
+
+Een **Sprint Retrospective** (of kort: een Sprint Retro) is de meeting op het einde van een Sprint waar het team bepaalt wat men kan wijzigen zodat de volgende Sprint meer productief wordt. Sprint Retrospectives verzamelen feedback en geven informatie over hoe de voortgang van een project verloopt.
+
+De [[007 Agile Projectmanagement#Product Owner|Product Owner]] kan toezien op deze meeting, maar in vele gevallen is dit een meeting met alleen maar de [[007 Agile Projectmanagement#De Developers|Developers]].
+
+> [!note] DEFINITIE: Sprint Retrospective
+> **Sprint Retrospective:** het event dat het einde van een Sprint uitmaakt, met een time-box van drie uur of minder. Tijdens dit event kijkt het Scrum Team terug op de aflopende Sprint, met als doel om op basis van de ervaringen in de huidige Sprint het proces en de manier van werken, in brede zin, voor de volgende Sprint te bepalen. [[./References/@verheyen_2022|@verheyen_2022]]
+
+Hier enkele voorbeelden van typische vragen die men kan vragen tijdens een Sprint Retrospectieve
+
+* wat waren onze succesvolle acties gedurende deze sprint?
+* wat leerden we van deze sprint?
+* wat gaan we blijven doen in de toekomstige sprints?
+* wat gaan we beter doen in de toekomstige sprints?
+* traden er problemen/fouten op?
+* heeft er nog iemand een vraag?
+* is er nog iets niet duidelijk voor iemand?
+
+## Scrum Artefacten
+De artefacten van Scrum vertegenwoordigen werk of waarde. Ze zijn ontworpen voor maximale transparantie van de belangrijkste informatie. Dankzij deze transparantie heeft iedereen, die deze artefacten inspecteert, dezelfde basis voor aanpassing.
+
+Elk artefact bevat een commitment om ervoor te zorgen dat het informatie geeft die de transparantie en de focus verhoogt, waaraan de vooruitgang kan worden gemeten:
+ - Voor de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]] is dit het Product Doel.
+ - Voor de [[007 Agile Projectmanagement#Sprint Backlog|Sprint Backlog]] is dit het [[007 Agile Projectmanagement#Sprint Doel|Sprint Doel]].
+ - Voor het [[007 Agile Projectmanagement#Incrementele ontwikkeling|Increment]] is dit de [[007 Agile Projectmanagement#Definition of Done|Definition of Done]]
+
+Deze commitments bestaan om empirisme en de Scrum waarden te versterken voor het Scrum team en zijn belanghebbenden.
+
+## Overzicht van de 5 Scrum Events
+
+
+[[./References/@visualparadigm_2022|@visualparadigm_2022]]
+
+We hebben ze nu allemaal gezien, maar hoe hangt Scrum nu alweer aan elkaar? En welke zijn de vijf Scrum Events?
+
+> [!summary] Samengevat
+> De vijf Scrum Events zijn:
+>
+> 1. De [[007 Agile Projectmanagement#Sprint Planning|Sprint Planning]] meeting
+> 2. De [[007 Agile Projectmanagement#Daily Standups|Daily Scrums]] *(of "Daily Standups")*
+> 3. De [[007 Agile Projectmanagement#Sprint Review|Sprint Review]] meeting
+> 4. De [[007 Agile Projectmanagement#Sprint Retrospective|Sprint Retrospective]] meeting
+> 5. De [[007 Agile Projectmanagement#Sprints|Sprint]]
+
+De Sprint begint met de Sprint Planning waarin we plannen wat we gaan maken, we hebben de dagelijkse Daily Scrums waarin we mogelijke impediments zo vlug mogelijk oplossen. Op het eind van een Sprint wordt getoond wat er gemaakt werd tijdens de Sprint Review en ten slotte gaat het team tijdens de Sprint Retrospective terugblikken naar de voorbije Sprint om te bepalen hoe hun werkwijzes nog te verbeteren.
+
+Merk op dat de [[007 Agile Projectmanagement#Product Backlog Refinement|Product Backlog Refinement]] – al is het een gebruikelijk event, en zeker geen onbelangrijk – niet tussen de vijf officiële Scrum Events staat.
+
+### What is Scrum? (Video)
+
+VIDEO
+
+## Hulpmiddelen en tools tijdens de Sprint
+
+### Storypunten
+
+
+
+#### Storypunten zijn relatief
+
+Storypunten *(vert. Engels: storypoints)* vertegenwoordigen een waarde die alleen belangrijk is voor het Scrum Team door met punten in te schatten hoe groot een item in de backlog is. Het geeft het team de mogelijkheid te bepalen welke items ze oppakken in een Sprint. De [[007 Agile Projectmanagement#Product Owner|Product Owner]] kan aan de storypunten zien welke items relatief duur zijn om door het team te laten maken. **De punten geven een beeld van de omvang en de moeite die het kost om de items in de backlog door het team te laten maken.**
+
+De waarde van de storypunten is gebaseerd op de reeks van Fibonacci. Hierin lopen getallen steeds op met het getal ervoor, waarbij de waarden 20, 40 en 100 er vooral zijn om aan te geven dat een item te groot is. In de praktijk splitsen we deze items tot kleinere.
+
+Dankzij storypunten kan een Scrum Team voor zichzelf een eenheid creëren om User Stories in te schatten. De punten representeren een relatieve waarde, en betekenen voor elk team iets anders.
+
+**We raden altijd aan om met storypunten te werken.**
+Probeer tijdsindicaties te vermijden. Waar het ene teamlid vier uur voor een User Story nodig heeft, kost hetzelfde klusje een ander teamlid zes uur.
+
+Door een eenheid te creëren die voor het hele team hetzelfde is, voorkomen we discussies over tijd en teamleden. In plaats van te kijken hoe lang een User Story duurt, richten we ons op de omvang van de klus.
+
+#### Wat betekent de relatieve waarde?
+
+De storypunten geven een beeld van de omvang van een User Story. Een User Story van 3 punten is groter dan een story van 1 punt, en kleiner dan een story van 5.
+
+#### Wat schat je in?
+
+Om het aantal punten van een User Story te bepalen, kijkt het team naar drie factoren die aangeven hoeveel moeite kost het om de User Story af te ronden?
+
+**Hoeveelheid**
+Hoeveel werk is het om de User Story volledig(!) af te ronden, volgens de [[007 Agile Projectmanagement#Definition of Done|Definition of Done]]?
+
+**Complexiteit**
+Hoe ingewikkeld is het om de User Story te maken? Is het makkelijk, of juist uitdagend?
+
+**Onzekerheid**
+Hoe groot is de kans dat we verrassingen tegenkomen die we vooraf niet hadden voorspeld?
+
+Samen bepalen deze factoren de hoeveelheid punten van een user story.
+
+==Bij een lage complexiteit, risico en moeite, krijgt de story een lage storypunt.==
+
+#### Hoe kun je er zelf mee starten?
+
+Om met storypunten te starten, moet je team eerst een **referentie-story bepalen** waarmee je alle andere stories kunt vergelijken. Kies hiervoor een redelijk complexe User Story die een zo hoog mogelijk aantal disciplines van je team omvat. Geef deze story 5 of 8 punten. Dan heeft je team nog genoeg ruimte om stappen naar boven en beneden te nemen. Je kunt de referentie-story tijdens [[007 Agile Projectmanagement#Product Backlog Refinement|Product Backlog Refinement]]s gebruiken om te bepalen of een andere User Story kleiner of groter is, en welke waarde je hieraan kunt geven.
+
+> [!abstract] Samengevat
+> Storypunten zijn een relatieve waarde die je samen met je Scrum Team creëert. Ze bieden inzicht in de moeite die het kost om een User Story te maken. De Product Owner kan afwegen om een bepaald item al dan niet te prioriteren. En het team weet hoeveel storypunten het per Sprint kan oppakken.
+[[./References/@vrielink_2020|@vrielink_2020]]
+
+#### What are Story Points (Video)
+
+VIDEO
+
+### De Burndown Chart
+
+Tijdens een Sprint toont een burndown chart voor het project hoeveel werkuren er op dagbasis nog overschieten. De dagen zie je van links naar rechts onderaan de grafiek en de uren zie je aan de linkerzijde.
+
+Kijkend naar de Burndown Chart kun je zien of een project nog "on target" is, voorloopt of achterophinkt.
+
+> [!caption]
+> 
+> Afbeelding: de burndown chart
+
+Meerdere mogelijke varianten, of manieren waarop je een burndown chart kan opstellen bestaan. Daar je in Scrum eerder in storypunten inschat, kiest men dan de verticale as af te zetten tegen de overgebleven storypunten i.p.v. de uren.
+
+#### How to use The Sprint Burndown (Video)
+
+VIDEO
+
+### Velocity
+
+Velocity is de snelheid waartegen teams werk afronden. Meer bepaald, de som van de storypunten van de items van de backlog die het team succesvol kan afronden in 1 Sprint,
+
+Eenmaal men de velocity kent na een aantal Sprints, kan men deze waarde gebruiken om het plannen van projecten te helpen en te voorspellen welke opleverdatum te voorzien.
+
+> [!caption]
+> 
+> Afbeelding: de velocity chart [[./References/@adobeworkfront_2022|@adobeworkfront_2022]]
+
+> [!note] DEFINITIE: Velocity
+> **Velocity:** een veelgebruikte aanduiding van de gemiddelde hoeveelheid [[007 Agile Projectmanagement#Product Backlog|Product Backlog]] die een specifiek team met zijn specifieke samenstelling tijdens een Sprint omgezet heeft in één of meerdere Incrementen. [[./References/@verheyen_2022|@verheyen_2022]]
+
+### Definition of Done
+
+Een Definition of Done geeft een duidelijke omschrijving van hoe een opgeleverde Product Backlog item er uit moet zien. Het is een manier om de kwaliteit van opgeleverde producten binnen [[007 Agile Projectmanagement#Scrum|Scrum]] te borgen. Het zorgt voor transparantie en duidelijkheid. Het ontwikkelteam geeft een commitment op het volgen van de Definition of Done.
+
+Een Definition of Done is een checklist met activiteiten je afgevinkt voor iedere User Story. **Dat betekent dat het activiteiten zijn die voor iedere [[007 Agile Projectmanagement#User Stories (en Epics)|User Story]] van toepassing zijn.**
+
+Je bereikt onder andere het volgende met een goede Definition of Done:
+
+1. Overeenstemming tussen het ontwikkelteam en de [[007 Agile Projectmanagement#Product Owner|Product Owner]] over wanneer een User Story daadwerkelijk klaar is. Heldere verwachtingen bepalen de basis voor goede samenwerking.
+2. Het verhogen van de snelheid waarmee werk wordt opgeleverd. Doordat je een algemeen geldende checklist hebt die je kan afvinken kun je snel werk van hoge kwaliteit leveren.
+
+> [!note] DEFINITIE: Definition of Done
+> **Definition of Done:** de verzameling kwaliteiten, verwachtingen en criteria waaraan een Increment moet voldoen om te kunnen worden vrijgegeven naar de eindgebruikers – met respect voor overkoepelende organisatierichtlijnen indien beschikbaar. [[./References/@verheyen_2022|@verheyen_2022]]
+
+De Definition of Done wordt tijdens de start van iedere [[007 Agile Projectmanagement#Sprints|Sprint]] in de [[007 Agile Projectmanagement#Sprint Planning|Sprint Planning]] herhaald. Daarnaast wordt de Definition of Done aangescherpt op basis van voortschrijdend inzicht.
+
+> [!example] Voorbeeld van een DoD (Definition of Done) voor een IT-project
+> - Alle code is geschreven (alle ‘to do’ items in de code zijn afgewerkt).
+> - Relevante gebruikersdocumentatie is gemaakt en beschikbaar gesteld.
+> - Er is een installatiehandleiding voor de installatie van de software.
+> - Alle functionele testen zijn gedraaid.
+> - Code heeft een peer review ondergaan.
+[[./References/@agilescrumgroup_2017|@agilescrumgroup_2017]]
+
+> [!example] Voorbeeld van een DoD voor een niet-IT-project
+>
+> • Alle to-do’s voor de story zijn afgerond.
+> • Een ander teamlid heeft feedback gegeven op het werk.
+> • Er is een spellingscheck gedaan.
+> • Het werk is gecontroleerd op huisstijl.
+> • Het werk is gecontroleerd op _design_ en _brand values_.
+> • Het werk is gecontroleerd in het kader van compliance.
+> • Er is feedback van eindgebruikers gevraagd op het opgeleverde product.
+
+Wat de inhoud van _Definition of Done_ is, bepaalt het team dus helemaal zelf.
+
+### Scrum bord
+
+
+
+Binnen Scrum wordt gewerkt met een Scrum bord *(synoniem: 'takenbord' of 'Kanban-bord')*. Het Scrum takenbord is bedoeld als hulpmiddel bij het overzichtelijk maken van de stand van zaken binnen een Sprint. De [[007 Agile Projectmanagement#Sprint Backlog|Sprint Backlog]] bevat alle taken geselecteerd voor een Sprint. Die taken hangen op post-its in één van de drie kolommen op het bord: To Do, Doing of Done. De belangrijkste taken hangen boven aan het bord. Dit bord geeft in één oogopslag inzicht in de status van een Sprint:
+
+- **To do.** Alle taken die men plant uit te voeren binnen de Sprint.
+- **Doing.** De taken binnen de Sprint waar op dat moment aan gewerkt wordt.
+- **Done.** Alle beëindigde taken binnen de Sprint.
+
+Het doel is om aan het einde van iedere Sprint alle taken onder de laatste kolom te hebben geplakt. Dat betekent dat alle vooraf bepaalde taken werden uitgevoerd en dat het doel van de Sprint behaald is. Het takenbord is voor het Scrum Team de centrale plaats om de aanpak van het resterende werk af te stemmen. Het takenbord wordt een **Scrum Board** genoemd, en wordt gebruikt tijdens de [[007 Agile Projectmanagement#Daily Standups|Daily Scrums]].
+
+Wanneer de Sprint is afgelopen en niet alle taken staat onder ‘Done’ dan plaatsen we de niet beëindigde taken terug in de [[007 Agile Projectmanagement#Product Backlog|Product Backlog]]. De [[007 Agile Projectmanagement#Product Owner|Product Owner]] kijkt dan vervolgens of deze taken in de volgende Sprint passen.
+[[./References/@scrumguide_2022a|@scrumguide_2022a]]
+
+## Scrum Waarden
+
+> [!note] DEFINITIE: Scrum Waarden
+> **Scrum Waarden:** een verzameling van vijf kernwaarden die het Scrum raamwerk schragen: commitment, focus, openheid *(Engels: ‘openness’)*, respect en moed *(vert. Engels: ‘courage’)*. [[./References/@verheyen_2022|@verheyen_2022]]
+
+
+
+### Commitment
+
+Commitment gaat over inzet, toewijding en inspanning, niet zozeer over het behalen van een vooropgesteld resultaat.
+
+Alle individuele spelers committeren zich aan het team: aan kwaliteit, aan samenwerking en aan voortdurend leren en bijsturen. Er is commitment om hard te werken en te doen wat mogelijk is, elke dag opnieuw. Er is commitment aan het [[007 Agile Projectmanagement#Sprint Doel|Sprint Doel]], commitment aan professioneel gedrag. Er is commitment aan zelfsturing, aan de principes beschreven in het Agile Manifesto. Men committeert zich om werkende software op te leveren en er is commitment aan voortdurende openheid voor verbeteringen. Een team committeert zich aan de [[007 Agile Projectmanagement#Definition of Done|Definition of Done]], aan de regels van het Scrum raamwerk. Er is commitment om waarde op te leveren, om werk daadwerkelijk af te ronden. Er is commitment aan volle transparantie, evenals commitment om elke status quo ter discussie te stellen.
+
+### Focus
+
+Scrum moedigt spelers aan om zich te concentreren op wat _nu_ het belangrijkst is, zonder afleiding door wat, wie weet, in een verder onbepaalde toekomst, mogelijk belangrijk is. We focussen op de actueel beschikbare kennis, _nu_.
+
+Dankzij het [[007 Agile Projectmanagement#Sprint Doel|Sprint Doel]] heeft een team een focus, een oriëntatiepunt voor de volgende vier weken of korter. Binnen die periode zorgt de [[007 Agile Projectmanagement#Daily Scrum|Daily Scrum]] ervoor dat mensen gezamenlijk focus houden op de dagelijkse werkzaamheden die hen naar die doelstelling helpen.
+
+### Openheid
+
+De [[007 Agile Projectmanagement#Empirische procescontrole|empirische procesfundamenten]] van Scrum vereisen transparantie, wat op zich openheid en eerlijkheid impliceert.
+
+ Alle spelers delen openlijk de werkelijke status van hun werk, hun voortgang, hun inschattingen, hun problemen en hun moeilijkheden. Alle spelers staan open voor het feit dat softwareontwikkeling gebeurt door en voor _mensen_ en niet door ‘resources’, robots of vervangbare machineonderdelen.
+
+De spelers tonen openheid voor samenwerking met andere disciplines en functies, openheid om functieomschrijvingen te overstijgen. Ze tonen openheid naar de [[007 Agile Projectmanagement#stakeholders|stakeholders]] en de bredere omgeving. Ze delen openlijk feedback en geleerde lessen. De spelers in Scrum staan open voor verandering, omdat ze erkennen dat hun organisatie en de wereld waarin zij en hun organisatie opereren voortdurend veranderen. Onverwacht en onvoorspelbaar, maar telkens voortdurend.
+
+### Respect
+
+Binnen het bredere ecosysteem dat ontstaat rond Scrum heerst een sfeer van respect: respect voor mensen, voor de andere spelers en de andere teams; respect voor hun inzichten, kennis en ervaring, respect voor hun afkomst en persoonlijke achtergrond. De spelers respecteren – en waarderen – diversiteit als bron en sleutelelement voor nieuwe en mogelijk botsende ideeën. Ze hebben respect voor andere meningen.
+
+De spelers van de teams tonen respect voor de omliggende organisatie door zich niet te gedragen alsof ze op een afgelegen eiland werken. Er is respect voor klanten, gebruikers en hun veranderlijke verwachtingen of ideeën. Teams tonen respect voor sponsors en geldschieters door geen onnodige features te behouden, die alleen maar de onderhoudskosten van de software verhogen. Teams tonen respect door geen tijd, inspanningen en budget te verkwisten aan taken, producten of productonderdelen die geen waarde hebben, noch voor de gebruikers, noch voor de organisatie. Ze respecteren gebruikers door de problemen die deze ondervinden, op te lossen. Teams tonen zich respectvolle professionals door geen _crappy_ software in productie te zetten.
+
+Alle spelers respecteren de regels van het Scrum raamwerk en de aansprakelijkheden die daaruit voortvloeien.
+
+### Moed
+
+Alle spelers tonen moed door geen software te bouwen waar niemand op zit te wachten. Moed zit vervat in de onderkenning dat requirements nooit perfect zijn, en dat geen plan ooit de complexe werkelijkheid kan voorspellen.
+
+Men toont moed als men veranderende inzichten, meningen en verwachtingen als een bron van inspiratie en vernieuwing beschouwt, in plaats van als een bron van ergernis. Het vergt moed om tijdelijke opleveringen uit te voeren, software te tonen die niet volledig en perfect lijkt, maar wel waarde levert of toevoegt. Alle spelers tonen moed door op elk gewenst moment de nodige informatie te delen die het team en de organisatie vooruithelpt. Spelers zijn moedig als ze erkennen dat niemand perfect is. Er is de moed om meer of minder radicaal van richting te durven veranderen, om een ander idee dan het eigen idee te omarmen, moed om zowel risico’s als voordelen te delen. Het vereist moed om de oude, valse zekerheden los te laten.
+
+De spelers tonen moed als ze Scrum correct toelichten als een empirisch proces, vanuit de moed om toe te geven dat aanpasbaarheid de enige manier is om met complexiteit om te gaan. Ze hebben de moed om de kernwaarden van Scrum te leven en te beleven, om een beslissing te nemen, tot actie over te gaan, niet tot een impasse verleid te worden, en vervolgens de moed tonen om genomen beslissingen gemaakt met ervaring opnieuw kritisch tegen het licht te houden en bij te sturen.
+[[./References/@verheyen_2017|@verheyen_2017]]
+
+### The Five Scrum Values (Video)
+
+VIDEO
+
+# Wat hebben we geleerd?
+
+
+
+We leerden wat [[007 Agile Projectmanagement#Wat betekent Agile|Agile]] betekent en dat we daar [[007 Agile Projectmanagement#Incrementele ontwikkeling|incrementeel]] en [[007 Agile Projectmanagement#Iteratieve ontwikkeling|iteratief]] te werk gaan.
+
+Vervolgens gingen we in detail naar [[007 Agile Projectmanagement#Scrum|Scrum]] kijken, de meest gebruikte uitvoering van Agile.
+
+We zagen dat Scrum bestond uit [[007 Agile Projectmanagement#Overzicht van de 5 Scrum Events| 5 Scrum Events]], die tijdens een [[007 Agile Projectmanagement#Sprints|Sprint]] plaatshebben.
+
+We maakten kennis met [[007 Agile Projectmanagement#De drie Rollen in Scrum|De drie Rollen in Scrum]] en we leerden wat ze betekenen.
+
+Verder bekeken we definities, tools en hulpmiddelen die we gebruiken tijdens de uitvoering van Scrum.
+
+- [[007 Agile Projectmanagement#Product Backlog|Product Backlog]]
+- [[007 Agile Projectmanagement#User Stories (en Epics)|User Stories]]
+- [[007 Agile Projectmanagement#Scrum Artefacten|Scrum Artefacten]]
+- [[007 Agile Projectmanagement#Stakeholders|Stakeholders]]
+- [[007 Agile Projectmanagement#Impediment|Impediment]]
+- [[007 Agile Projectmanagement#Acceptatie Criteria|Acceptatie Criteria]]
+- [[007 Agile Projectmanagement#Sprint Doel|Sprint Doel]]
+- [[007 Agile Projectmanagement#Sprint Backlog|Sprint Backlog]]
+- [[007 Agile Projectmanagement#Product Backlog Refinement|Product Backlog Refinement]]
+- [[007 Agile Projectmanagement#De Burndown Chart|De Burndown Chart]]
+- [[007 Agile Projectmanagement#Velocity|Velocity]]
+- [[007 Agile Projectmanagement#Storypunten|Storypunten]]
+- [[007 Agile Projectmanagement#Scrum bord|Scrum bord]]
+- [[007 Agile Projectmanagement#Definition of Done|Definition of Done]]
+
+Wat we zeker nooit gaan vergeten is dat Scrum meer is dan een verzameling regeltjes, rollen en events.
+
+> [!caption]
+> 
+> Afbeelding: De Scrum waarden
+
+De basis van Scrum is een verzameling van [[007 Agile Projectmanagement#Scrum Waarden|kernwaarden]] in combinatie met het correct toepassen van [[007 Agile Projectmanagement#Empirische procescontrole|empirisch denken]].
+
+> [!important] Belangrijk
+> **Een degelijke kennis van de theorie is essentieel, maar enkel door toepassing van de basis gaat ze renderen tegen het volledig potentieel.**
+
+
+
+# De zin en onzin van tijdsregistratie in Agile projecten - geen examenleerstof
+
+
+
+Het registreren van tijd in een agile project is een veelbesproken onderwerp, vooral omdat ontwikkelaars in Scrum Teams zeggen dat het in strijd is met de Agile Principes (*"Werkende software boven allesomvattende documentatie"*).
+
+Toch zijn veel agile coaches het erover eens dat de prestaties verbeteren als tijd wordt bijgehouden als individuele activiteit en niet als managementvereiste.
+
+Scrum en Agile methodologieën zijn flexibel en makkelijk aanpasbaar, waardoor ontwikkelaars meer werk kunnen doen. Het is belangrijk dat je de juiste trackingmetriek kiest om het project sneller te laten verlopen.
+
+## Voordelen van tijdsregistratie
+
+Tijdsregistratie in Jira maakt een nauwkeuriger meting van de voortgang van een project mogelijk. Product Owners kunnen zien hoeveel tijd er aan een Story is besteed en hoeveel tijd er nog over is. Het team krijgt door middel van continue uurupdates een vrij nauwkeurige weergave van de voortgang van de Sprint en kan helpen blokkades op te lossen wanneer een probleem langer aanhoudt.
+
+Zo wordt het ook voor ontwikkelaars eenvoudig om historische gegevens op te halen voor toekomstige Sprints, Sprint Planningen, de Sprint Backlog invulling en Sprint Retrospectives.
+
+Ze weerspiegelen de werkelijkheid, creëren transparantie en helpen het projectbudget te volgen en de winstgevendheid van het project te voorspellen.
+
+Bovendien wordt tijdsregistratie in een bedrijfscontext gebruikt als tool om transparantie naar de klant te garanderen en om facturatie te verantwoorden.
+
+In onze context, het onderwijs, is tijdsregistratie een manier om de bijdrage van elke student zichtbaar te maken.
+
+## Nadelen van tijdsregistratie
+
+Ondanks het feit dat iedereen het erover eens is dat tijdsregistratie veel voordelen heeft voor een Scrum Team, kan het systeem de voortgang belemmeren als het niet correct wordt uitgevoerd. Het kan het team schaden als je vraagt de tijd bij te houden als een micromanagementtechniek[^micromanagement], wat in strijd is met de Agile methodologie.
+
+[^micromanagement]: Micromanagement is een managementstijl waarbij een leidinggevende zeer nauw toezicht houdt op en vaak te gedetailleerd betrokken is bij het werk van zijn of haar medewerkers. Dit betekent doorgaans dat een manager niet alleen bepaalt wat er gedaan moet worden, maar ook precies hoe en wanneer het moet gebeuren, soms tot op het punt dat elke kleine stap wordt gecontroleerd en voorgeschreven. Dit kan leiden tot een gebrek aan autonomie en creativiteit bij werknemers, en vaak tot frustratie en een lagere werktevredenheid.
+
+Handmatige urenregistratie vertraagt de ontwikkelaars en vermindert hun productiviteit. Bovendien groeit de kans dat ontwikkelaars uren gaan 'fantaseren' of ze op vage of algemene taken gaan boeken, wat leidt tot verkeerde schattingen, foutieve gegevens en een verlies aan factureerbare uren.
+
+## Tijdsregistratie op een Agile manier
+
+Hoewel er geen direct verband is tussen het bijhouden van tijd en de kwaliteit van code, heeft een Product Owner wel verantwoordelijkheden tegenover het management, klanten en belanghebbenden. Wanneer een project langer duurt dan verwacht vanwege wijzigingen in de scope, geven urenstaten een gedetailleerd inzicht in de status van het project en de productiviteit van het Scrum Team.
+
+Belangrijk is de juiste context te koppelen met de juiste registratie.
+
+## Practische handleiding
+
+**Scenario 1: Doe je iets in de context van een Story, boek dan je uren op die Story**
+
+
+Agile teams werken aan User Stories; alles wat je doet is waardevol voor de klant, en die waarden worden uitgeschreven in stories.
+
+In elk van de volgende scenario's boek je je uren onder de betreffende story, met een relevante beschrijving:
+
+1. Je werkt aan acceptatiecriteria voor een story en voegt deze toe aan de beschrijving van de story in Jira.
+2. Je doet als developer technisch onderzoek dat nodig is om een story te kunnen beginnen.
+3. Je schrijft code voor een story.
+4. Je beoordeelt een pull request van een collega-developer voor een story.
+5. Je schrijft unittesten voor een story.
+6. Je test een story om te zien of deze voldoet aan de acceptatiecriteria.
+
+In principe boek je het merendeel van het werk onder stories.
+
+**Scenario 2: Ben je bezig met taken die niet strikt in de context van een story vallen, boek dan je uren op die specifieke taak.**
+
+
+Tot dergelijke taken behoren het schrijven van een projectplan, het voorbereiden van een presentatie, het opzetten van de CI/CD-omgeving, het aanmaken van een Git-repository, het werken aan een afstudeer-specifieke taak, enz. Ook het opstellen van documentatie voor een specifieke opdracht valt hieronder. Deze activiteiten hebben, strikt genomen, geen directe waarde voor de klant — niet dat ze waardeloos zijn, want ze helpen de kwaliteit van het product te waarborgen, maar ze voegen geen rechtstreekse functionaliteit toe voor de klant. Daarom kwalificeren ze niet als User Stories, maar als **Taken**.
+
+Let erop dat we geen algemene of vage taken zoals 'testen van de code' of 'vergaderingen' willen zien in de urenregistratie. Dit zijn indicatoren dat er onvoldoende transparantie is in de werking van het team. Dergelijke taken zijn waarschijnlijk onderdelen van een User Story (scenario 1), of een Scrum Event (Scenario 3).
+
+**Scenario 3: Wanneer je deelneemt aan een van de Scrum Events, registreer dan de uren onder een taak genaamd 'Scrum Events', met de naam van het specifieke event als beschrijving.**
+
+
+In principe is deze vorm van tijdsregistratie niet nodig, aangezien alle teams de Scrum Events houden en alle teamleden deelnemen aan deze activiteiten. In een volwassen bedrijfscontext gaan teams er vaak van uit dat 20% van de tijd besteed wordt aan de Scrum Events, wat betekent dat slechts 80% van de tijd (8 uur x 80% = 6,4 uur) als productieve werktijd wordt beschouwd.
+
+Omdat we momenteel nog geen volwassen teams zijn, maken we voor iedere Sprint een taak aan genaamd 'Scrum Events' en boeken daar de tijd voor elk afzonderlijk event op.
+
+## Boek je uren op Stories/Taken? Of op subtaken onder Stories/Taken?
+
+
+In principe maakt het niet uit welke van de twee opties je kiest, maar kies zeker per team consistent voor een van de twee opties.
+
+Indien je graag achteraf gegevens wilt hebben over de tijd die is besteed aan analyse, ontwikkeling, en testen, of aan back-end/front-endontwikkeling op storyniveau, **en wanneer je dankzij deze data daadwerkelijk actie onderneemt die de werking van het team optimaliseert**, kan het handig zijn om subtaken te gebruiken. ==In dat geval registreer je de uren op de subtaak==.
+
+Maak je geen analyses, of wordt dit niet gedaan door je bedrijf, docent of welke andere controlerende instantie dan ook, ==dan is de keuze om uren te registreren met een relevante omschrijving op storyniveau meer dan voldoende en voorkom je onnodig administratief werk voor het team==.
+
+Je kunt perfect zien hoeveel tijd het team heeft besteed aan de story. Wees in dat geval duidelijk in je omschrijving en maak goede afspraken.
+
+# Bibliografie
+
+- [[./References/@adobeworkfront_2022|@adobeworkfront_2022]]: _'What is Velocity in Agile? Charts & Examples | Adobe Workfront'_ - **Adobe Workfront,(2022)** https://www.workfront.com/project-management/methodologies/agile/velocity