Scrum Begrippen

De begrippen van het Scrum Framework


Scrum kent veel specifieke termen. Wij bieden u graag een overzicht:


Agile

Overkoepelend gedachtegoed voor methodieken en frameworks voor software ontwikkeling, die voldoen aan de pricipes zoals gesteld in het Agile Manifesto:

Mensen en hun onderlinge interactie boven processen en hulpmiddelen
Werkende software boven allesomvattende documentatie
Samenwerking met de klant boven contractonderhandelingen
Inspelen op verandering boven het volgen van een plan

Hoewel wij waardering hebben voor al hetgeen aan de rechterkant staat vermeld, hechten wij méér waarde aan wat aan de linkerzijde wordt genoemd.


Backlog Refinement

Het verduidelijken, verbeteren, prioriteren en schatten van de Product Backlog. Vaak gebeurt dit in een workshop met het team en de Product Owner, waarin gezamenlijk wordt gekeken naar de details van de Product Backlog items.


Corporate backlog

Een geprioriteerde lijst met doelen, acties en producten die een bedrijf wil gaan leveren of uitvoeren.


Cross-functional team

Samenwerking tussen en over de verschillende functies heen / functie-overschrijdende samenwerking. Bijvoorbeeld wanneer software ontwikkelaars, informatie analisten, testers, ontwerpers in één team.


Daily Scrum

Elke dag houdt het team een korte meeting van 15 minuten die Daily Scrum of Daily Standup wordt genoemd. Het doel van deze meeting is zorgen dat iedereen zo effectief mogelijk bezig is. Om de meeting kort en effectief te houden blijft iedereen staan en beantwoord de volgende 3 vragen:

  • Wat heb ik gedaan sinds de vorige meeting?
  • Wat ga ik doen tot de volgende meeting?
  • Welke issues heb ik en welke hulp heb ik daar bij nodig?

Definition of Done

De Definition of Done beschrijft waar het resultaat van een Sprint aan moet voldoen. Het is een hulpmiddel voor het team om de kwaliteit van het werk constant te houden. De Definition of Done wordt door het team zelf opgesteld en beschrijft dingen als testen, unittesten, documentatie enz.


Development Team

Een cross-functioneel, zelfsturend team, van minimaal 3 en maximaal 9 personen. Zij zijn verantwoordelijk voor het opleveren (en hebben daarvoor de juiste personen) van een potentieel ‘verscheepbaar’ gedeelte van het product, aan het eind van de sprint.


Epic

Een epic heeft dezelfde vorm als een User story, alleen omvat deze een grotere scope.


Happiness metric

De Happiness metric kan worden gebruikt om het gevoel in een team te meten. Hoe blij/gelukkig zijn de teamleden. Tevens geven de teamleden aan wat er moet gebeuren om hun gevoel te verbeteren.


(Shippable) Increment

Het product dat het Scrum team aan het einde van een sprint oplevert. Het product voldoet aan de afgesproken Definition of Done. Het moet in bruikbare conditie zijn. Ongeacht of de Product Owner daadwerkelijk besluit het product op de markt te brengen.


Pair programming

Een toepassing van eXtreme Programming (XP), waarin twee software ontwikkelaars samen achter een computer zitten en aan code werken.


Planning poker

Planning poker is een format om een relatieve schatting te maken van de ' implementation effort' van een Product backlog item. Het gaat hierbij vooral om de conversatie. Iedereen geeft door middel van kaarten aan hoeveel werk een Backlog Item inhoudt. Verschillen in die inschatting worden besproken waarna het kaarten zich herhaalt totdat er consensus wordt bereikt. De discussie die deze manier van inschatten oplevert zorgt ervoor dat iedereen betrokken is.


Portfolio backlog

High-level backlog op portfolio niveau (die gebruikt wordt in het Scaled Agile Framework) Het is een geprioriteerde lijst van epics of features die voor de toekomst op de planning staan.


Product backlog

De Product backlog is een lijst met het resterende werk voor het product. Alle Product backlog items zijn voorzien van een waarde, bijvoorbeeld waarde voor de business. De items worden door het team van een relatieve inschatting voor de hoeveelheid werk voorzien. Op basis van de verwachtte waarde en de vereiste inspanning kan de Return On Investment (ROI) berekend worden. De Product Backlog kan op basis van de ROI worden geprioriteerd, maar bijvoorbeeld ook op afhankelijkheden met andere Product backlog items. Items die hoger geprioriteerd zijn, zijn over het algemeen duidelijker gespecificeerd, zodat de items opgenomen kunnen worden in een volgende sprint.


Product backlog items

Alles wat er op een product backlog staat is een product backlog item. Product Backlog items hebben als kenmerken een beschrijving, ordening, een schatting en een waarde.


Product backlog management

Goed Product Backlog management omvat o.a.:

  • Helder omschrijven van Product Backlog items
  • Ordenen van Product Backlog items, om doelen en missie op de beste manier te behalen
  • Optimaliseren van de waarde van het werk dat het Development team uitvoert
  • Ervoor zorgen dat de Product backlog zichtbaar, transparant en duidelijk is voor iedereen, en dat het laat zien waar het Scrum Team aan gaat werken.
  • Ervoor zorgen dat het Development team de Product backlog items begrijpt tot het niveau dat benodigd is.


Product Owner

De Product Owner is verantwoordelijk voor het bijhouden van de Product Backlog, door het vertegenwoordigen van de belangen van alle stakeholders. Tevens is de Product Owner verantwoordelijk voor het maximaliseren van de waarde van hetgeen het development team oplevert. De Product Owner is één persoon, geen comité.

Bekijk hier onze gecertificeerde Professional Scrum Product Owner Trainingen.

Project Start Architecture document

Een Project Start Architecture is bedoeld om vooraf te borgen dat nieuwe ontwikkelingen en veranderingen welke in een project gerealiseerd gaan worden passen binnen bestaande en/of toekomstige organisatie- of domeinarchitectuur.


Reference architecture

Een template oplossing voor een architectuur binnen een domein. De referentie architectuur kan gebruikt worden om een gezamenlijk uitgangspunt te hebben om over software implementaties te discussiëren en kan dienen als uitgangspunt om de uiteindelijke architectuur vorm te geven.


Release burn-down chart

Een grafiek die aangeeft hoeveel van de release nog gerealiseerd moet worden. De grafiek loopt af, naar een vooraf besproken doel.


Release burn-up chart

Een grafiek die aangeeft hoeveel van een release al is gerealiseerd. Elke sprint komt er weer een nieuw increment bij, waardoor de release burn-up groeit en dichterbij het einddoel komt.


Requirements

Alle eisen en wensen die een klant stelt aan de software. Dit kunnen onder andere functionele eisen, performance eisen, beheer eisen of klantwensen zijn.


Roadmap

Een roadmap is een prestatie- en doelgericht plan. In de roadmap wordt niet op de details ingegaan.


Rollen

Er zijn 3 rollen binnnen Scrum; de Product Owner, die de belangen van de klant vertegenwoordigt; de Scrum Master die het proces ondersteunt en het team, die in een korte tijd werkende software kan opleveren.


Scrum

Een framework/kader waarbinnen mensen complexe en bewerkelijke problemen kunnen aanpakken, terwijl ze productiever en creatiever producten kunnen leveren van de hoogst mogelijke waarde.

Scrum is: eenvoudig te begrijpen maar moeilijk te beheersen.

Scrum is een proces raamwerk dat sinds 1990 is gebruikt om complexe productontwikkeling te kunnen managen. Scrum is geen proces of een techniek om producten te bouwen; het is eerder een kader waarbinnen je verschillende processen en technieken kunt gebruiken. Scrum maakt duidelijk wat de relatieve efficiëntie is van je product management en ontwikkelingstechnieken, zodat je kan blijven verbeteren.


Scrum Master

De Scrum Master is een diendende leider die verantwoordelijk is voor het Scrum proces. Hij zorgt ervoor dat Scrum op de juiste manier wordt ingezet om zodoende maximale waarde door het development team te laten creëren.

Bekijk hier onze gecertificeerde Professional Scrum Master Trainingen.


Servant leader

De servant leader is een leider die, in tegenstelling tot een traditionele leider of manager, de verantwoordelijkheid deelt met zijn medewerkers, de behoefte van anderen voorop stelt en mensen helpt zich te ontwikkelen en het beste uit zichzelf te halen.


Sprint

Een time-box van een maand of minder, waarin een werkend software increment wordt opgeleverd, dat voldoet aan de definitie van "Done". Elke sprint is dezelfde lengte gedurende de gehele ontwikkeltijd en volgen elkaar direct op.

 

Sprint Backlog

De Sprint Backlog is de verzameling Product Backlog items die geselecteerd zijn voor de Sprint, inclusief het plan voor opleveren van het Product Increment en voor de realisatie van het Sprint Doel. De Sprint Backlog is een voorspelling door het Ontwikkelteam over de functionaliteit die aanwezig zal zijn in het volgende Increment en het werk dat nodig is om die functionaliteit te leveren in een “Klaar” Increment. De Sprint Backlog maakt al het werk zichtbaar dat het Ontwikkelteam heeft geïdentificeerd als noodzakelijk voor behalen van het Sprint Doel.


De Scrum methode is iteratief. Elke iteratie wordt een ‘Sprint’ genoemd. Een Sprint duurt 2 tot maximaal 4 weken. Binnen deze tijd pakt het team een vooraf geselecteerde hoeveelheid werk op wat helemaal afgemaakt wordt. Het resultaat van elke Sprint is een stukje werkende software. Daardoor is het product snel bruikbaar en krijgt het team snel feedback op het product en het proces.


Sprint burn-down chart

Dagelijkse voortgang van een sprint, aangegeven over de lengte van de sprint.


Sprint planning meeting

Het werk dat uitgevoerd moet worden tijdens een Sprint wordt gepland tijdens de Sprint planning meeting. Het maken van dit plan is een gezamenlijke inspanning van het gehele Scrum Team. De Sprint planning meeting beantwoordt de volgende vragen:

  • Wat kan worden geleverd aan het einde van de komende Sprint?
  • Hoe wordt het benodigde werk, om dit Product Increment te leveren, uitgevoerd?


Sprint Retrospective

De Sprint wordt afgesloten met de Sprint Retrospective. Tijdens deze meeting kijkt het team terug op het werkproces, de samenwerking, gebeurtenissen en de kwaliteit van de afgelopen Sprint. Dit heeft als doel om beter te worden. Alles wat niet goed ging moet worden aangepakt, zodat in volgende Sprints niet dezelfde fouten gemaakt kunnen worden. Punten die uit de Retrospective komen, zijn bij voorkeur ‘actionable’.


Sprint Review

Een Sprint Review wordt gehouden aan het einde van de Sprint om het Increment te inspecteren en indien nodig de Product Backlog aan te passen. Gedurende de Sprint Review bekijken het Scrum Team en de belanghebbenden samen wat er bereikt is gedurende de Sprint. Op basis hiervan en op basis van veranderingen in de Product Backlog, werken de aanwezigen samen aan de volgende stappen die genomen kunnen worden om waarde te optimaliseren. Dit is een informele bijeenkomst, geen status meeting, en de presentatie van het Increment heeft als doel feedback te verzamelen en samenwerking te bevorderen.


Scrum Board

Het Task Board, of Scrum Board, is een bord waar alle Sprint Backlog Items hangen. De taken op het bord zijn verdeeld over 3 kolommen: To Do, In Progress en Done. De belangrijkste taken hangen bovenaan het bord. De Sprint Backlog is daarmee ook gesorteerd op prioriteit. Samen met de Sprint burn-down chart geeft dit bord in één oogopslag inzicht in de huidige status. Het Scrum Board is voor het team de centrale plaats om het resterende werk en de aanpak af te stemmen.


Team

Het team is multidisciplinair en zelfsturend. Dat betekent dat het team zelfstandig in staat is alle taken van ontwerp, realisatie, testen tot en met de oplevering te verzorgen. Het team bestaat uit 5 tot en met 9 deelnemers. Het team is verantwoordelijk voor zowel het inplannen als het uitvoeren van het werk tijdens een Sprint. Het bijzondere van Scrum is dat het team zelf verantwoordelijk is voor het werkproces. Door elke Sprint af te sluiten met een evaluatie wordt continue gewerkt aan verbeteringen aan dit proces.


Team Velocity

De Velocity is de hoeveelheid werk die het team in één Sprint kan wegwerken. Tijdens elke Sprint wordt de hoeveelheid werk bijgehouden. Op basis van deze Velocity kan het team inschatten hoeveel werk het per Sprint aankan.


Test Driven Development

Een toepassing in Software ontwikkeling, waarin begonnen wordt met het schrijven van een test, die initieel faalt. Daarna wordt de software geschreven om de test te laten slagen. De falende test laten slagen is dus het uitgangspunt om de software te schrijven.


Timebox

Een afgesproken tijdskader waarbinnen een activiteit wordt uitgevoerd. Een Daily Scrum heeft bijvoorbeeld een timebox van 15 minuten.


User Stories

Een Product Backlog Item dat beschrijft ‘wat’ en ‘waarom’ de klant deze functionaliteit wil hebben. Het ‘hoe’ staat niet in de Story, omdat dit aan het team wordt overgelaten in de Sprint Planning meeting. User stories worden als volgt geschreven: Als (gebruiker), wil ik (feature), zodat ik (reden waarom/achterliggende behoefte)


Value Management

Techniek om voortgang te meten aan de hand van geleverde waarde.


Velocity

De Velocity is de hoeveelheid werk die het team bewezen heeft af te kunnen maken in één sprint. Tijdens elke Sprint wordt de hoeveelheid opgeleverd werk bijgehouden. De velocity is een hulpmiddel voor tijdens de Sprint planning meeting.


Meer weten over Agile/Scrum?

De toepassing van Scrum voor het ontwikkelen van software neemt sterk toe. Veel organisaties overwegen om Scrum toe te passen of werken al met een Scrum Team. Veel beschikbare hulpmiddelen en trainingen richten zich op de theorie van Scrum en slechts in mindere mate op de toepassing. Dit terwijl 'De Kracht van Scrum' juist ligt in het eenvoudig oppakken en toepassen ervan. Prowareness biedt u daarom de mogelijkheid om theorie en praktijk aan elkaar te koppelen door middel van de Professional Scrum Master en Professional Scrum Product Owner Training, inclusief certificering vanuit Scrum.org.


De Agile Academy biedt u een breed scala aan Agile opleidingen. Klik hier voor ons trainingsaanbod. Voor meer informatie over onze Agile Trainingen kunt u contact opnemen met onze Agile Academy via agileacademy@prowareness.nl of telefoonnummer 015 - 241 18 00.

Scrum Webshop