Onderstaand vindt u een aantal artikelen over het toepassen van Scrum. Dit beschrijft de basis voor een goede implementatie van Scrum.
Voor een volledige beschrijving van het Scrum raamwerk, zie de Scrum Guide van Ken Schwaber en Jeff Sutherland.

Het Scrum raamwerk

Scrum is een raamwerk voor het ontwikkelen en onderhouden van complexe producten. Het eindproduct hoeft dus niet per definitie ontwikkelde software te zijn. Alhoewel Scrum het breedst wordt toegepast binnen de software ontwikkeling, kan het ook binnen andere vakgebieden zijn toegevoegde waarde hebben.

Aangezien ik Scrum alleen toepas binnen de software ontwikkeling, wordt dit als uitgangspunt genomen in onderstaande beschrijvingen.
Een vertaling naar andere vakgebieden is vaak eenvoudig te maken.

Scrum is ontstaan vanuit het gedachtegoed achter het Agile Manifesto.
Dit manifest, dat is opgesteld door een aantal guru's op het gebied van software ontwikkeling, concludeert het volgende:

  • 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

Hiermee zegt het manifest dat aan hetgeen vetgedrukt is, meer waarde wordt gehecht dan aan hetgeen erachter genoemd wordt.
Dit houdt niet in dat er geen documentatie opgeleverd hoeft te worden, maar de kwaliteit van de software prevalleert boven de documentatie.

Ook de twaalf principes achter het Agile Manifesto zijn de moeite van het lezen (bestuderen) waard!

Terug naar Scrum. Het Scrum raamwerk bestaat uit Scrum Teams die vanuit bepaalde rollen structurele gebeurtenissen doorlopen en daarmee bepaalde producten ontwikkelen en beheren. Deze rollen, gebeurtenissen en producten worden hieronder verder beschreven.

Scrum kent de volgende uitgangspunten:

  • Scrum werkt op basis van Sprints; waarin vanuit een iteratief proces wordt gewerkt.
  • Transparantie en eenduidige afspraken zijn belangrijk, zodat iedereen weet waar hij/zij aan toe is. Dus geen verrassingen!
  • Er wordt vanuit de verschillende gebeurtenissen continu gecontroleerd of de ontwikkelingen nog het goede pad volgen. Ook hier geen verrassingen!
  • Er wordt zoveel mogelijk gebruik gemaakt van opgedane ervaring en feedback. Gebruik voortschrijdend inzicht!
    Aanpassingen van het oorspronkelijke idee zijn welkom en worden meteen verwerkt. Geen verrassingen achteraf!
  • Elke Sprint wordt er een potentieel opleverbare toevoeging gedaan aan het te ontwikkelen eindproduct.

Tot zover Scrum in een notendop. Hieronder een verdere uitwerking van de verschillende Scrum onderdelen.

Rollen

Rollen

Een Scrum Team kent de volgende rollen:

  • De Product Owner (één persoon, geen gremium o.i.d.) is verantwoordelijk voor het behalen van zoveel mogelijk toegevoegde waarde uit de ontwikkelde software. Hiermee is de Product Owner verantwoordelijk voor het beheer van de Product Backlog, hetgeen inhoudt dat de wensen helder zijn beschreven én geprioriteerd. Om dit alles te realiseren heeft de Product Owner continu contact met Gebruikers, Stakeholders en het Development Team. Om zijn rol te kunnen vervullen heeft de Product Owner het vertrouwen nodig van alle betrokkenen.

  • De Scrum Master (ook één persoon) is verantwoordelijk voor het Scrum proces. Dus de Scrum Master zorgt ervoor dat iedereen begrijpt wat Scrum is en wat er van hem/haar wordt verwacht. Zo kan de Scrum Master de Product Owner ondersteunen bij de wijze waarop deze de Product Backlog beheert, of hij kan problemen (impediments) voor het Development Team oplossen. De Scrum Master is geen hiërarchisch leider maar moet meer de rol van facilitator op zich nemen. Hij faciliteert het Scrum proces.

  • Het Development Team (drie tot negen personen) bestaat uit iedereen die nodig is om het product te kunnen leveren. Dus niet alleen ontwikkelaars, maar (indien nodig) ook business analisten, architecten, testers, etc. Zodra blijkt dat het Development Team niet voldoende heeft aan negen personen, moet het eindproduct worden opgedeeld over meerdere Scrum Teams. Elk Team krijgt dan bijvoorbeeld de verantwoording over een bepaald deel van de applicatie. Elk Scrum Team heeft een Product Owner en Scrum Master, maar de Product Backlog kan gedeeld worden.

Producten

Producten

Scrum kent de volgende producten:

  • De Product Backlog bevat alle wensen die nog bestaan voor de (door)ontwikkeling van een product. Voor alle gewenste functionaliteit, verbeteringen, oplossingen voor fouten, etc. wordt een Product Backlog Item toegevoegd aan de Product Backlog, waarbij deze lijst continu zo wordt gesorteerd, dat de Items met de meeste toegevoegde waarde bovenaan staan.
    Het beheer van de Product Backlog is een continu proces (Product Backlog refinement) waarvoor de Product Owner verantwoordelijk is. Ook de bestaande Items worden continu aangepast aan nieuwe inzichten. De Items die hoger op de lijst staan zijn meestal nauwkeuriger en meer gedetailleerd beschreven dan Items met een lage waarde.
    De Product Backlog is voor iedereen die er belang bij heeft toegankelijk. Per Item wordt minimaal een beschrijving opgeslagen, samen met de waarde (business value) ervan en de verwachtte capaciteit (estimate) die nodig is voor oplevering (dus inclusief documentatie, testen, etc.). Als meerdere Scrum Teams een Product Backlog delen, wordt een extra kenmerk toegevoegd om aan te geven voor welk Scrum Team het Item relevant is. Verder kunnen velden worden toegevoegd voor een Status, Categorie, etc.
     
  • De Sprint Backlog bevat alle Items die zijn geselecteerd voor de betreffende Sprint. Daarnaast hoort ook het plan voor de uitvoering, inclusief de taken en het Sprint Doel, tot de Sprint Backlog. De Sprint Backlog wordt tijdens de Sprint beheerd door het Development Team, door de taken verder uit te werken en de status van de Items up-to-date te houden. Hierdoor geeft de Sprint Backlog op elk moment binnen de Sprint weer, wat de voortgang van de Sprint is. De Product Owner en Scrum Master kunnen geen aanpassingen doorvoeren aan de Sprint Backlog, maar kunnen deze wel bekijken.

  • De Definition of Done beschrijft waaraan de uitgevoerde werkzaamheden moeten voldoen, voordat een Item kan worden gekenmerkt als gereed (Done). De Definition of Done wordt onderhouden tijdens de Sprint Retrospective. In deze definitie staat bijvoorbeeld beschreven wat moet worden gedocumenteerd, wat de minimale performance eisen zijn, wat en hoe getest moet worden, etc. Alle Items die aan het eind van de Sprint worden opgeleverd als "toevoeging op het eindproduct", voldoen dus aan de Definition of Done.

  • Elke Sprint wordt er een toevoeging op het eindproduct opgeleverd. Deze toevoeging bestaat uit de som van alle Items die zijn opgeleverd tijdens de Sprint, en moet potentieel opleverbaar zijn, dus volledig werkbaar en afgerond.

 

Gebeurtenissen

Gebeurtenissen

Scrum kent de volgende gebeurtenissen welke iteratief worden doorlopen:

  • Een Sprint is een periode van twee weken tot maximaal een maand, waarin aan de toevoeging op het eindproduct wordt gewerkt. De overige gebeurtenissen vinden eens of meerdere malen plaats binnen elke Sprint. Gedurende de Sprint worden er geen wijzigingen gedaan aan aan het Sprint Doel. Wel kunnen de Sprint Backlog Items tijdens een Sprint alsnog worden bijgesteld om het doel van de Sprint alsnog te halen. Door de Sprint kort te houden wordt het risico op desinvesteringen verkleind; aan het eind van elke Sprint kunnen Stakeholders zien wat er is opgeleverd. Als dit niet naar wens is kan direct worden bijgestuurd. 

  • De Sprint Planning wordt uitgevoerd aan het begin van elke Sprint en duurt voor een Sprint van een maand maximaal acht uur. Bij de Sprint Planning is het gehele Scrum Team aanwezig. De bijeenkomst wordt opgedeeld in twee delen, waarin de volgende vragen worden beantwoord:
    1. Wat kan er in de komende Sprint worden uitgevoerd? Eerst wordt het Sprint Doel gedefinieerd. Vervolgens wordt vanaf de bovenkant van de Product Backlog (van de items met de meeste toegevoegde waarde) een aantal items geselecteerd welke in de komende Sprint uitgevoerd worden om dit doel te bereiken. De Product Owner voegt de items toe aan de Sprint Backlog en licht ze functioneel toe, zodat helder is wat er in detail moet gebeuren. Het Development Team bepaald het aantal items dat het verwacht uit te kunnen voeren in de betreffende Sprint.

    2. Hoe kan dit werk worden uitgevoerd? In dit deel van de Sprint Planning wordt een plan gemaakt voor het uitvoeren van de geselecteerde Sprint Backlog Items. Voor alle items wordt een inschatting gemaakt van de benodigde capaciteit. Hiervoor worden de (eerste) items opgedeeld in taken, welke vaak technisch van aard zijn. Als blijkt dat er teveel items op de Sprint Backlog zijn geplaatst, worden de overige items teruggeplaatst naar de Product Backlog.

  • De Daily Scrum wordt elke dag op hetzelfde tijdstip en op dezelfde locatie gehouden en duurt maximaal 15 minuten.
    Alleen het Development Team doet mee aan deze korte bijeenkomst, anderen mogen natuurlijk wel aanwezig zijn.
    Tijdens de Daily Scrum verteld elk lid van het Development Team:
    • Wat hij de afgelopen 24 uur heeft gedaan om het Sprint Doel te bereiken
    • Wat hij de komende 24 uur gaat doen om het Sprint Doel te bereiken
    • Of hij problemen (impediments) ziet die het bereiken van het Sprint Doel in de weg staan.
    De afgeronde Sprint Backlog Items worden bijgehouden, zodat de resterende hoeveelheid werk op elk moment inzichtelijk is.
    Vastgestelde problemen kunnen direct ná de Daily Scrum worden opgelost door (leden van) het Development Team of door de Scrum Master.

  • De Sprint Review wordt uitgevoerd aan het einde van een Sprint en duurt voor een Sprint van een maand maximaal vier uur.
    Tijdens de Sprint Review demonstreert het Development Team de toevoeging op het eindproduct die tijdens de Sprint is ontwikkeld. Bij deze demonstratie kunnen naast de leden van het Scrum Team ook Stakeholders uitgenodigd worden. Op basis van de ontvangen feedback kan ter plekke de Product Backlog worden bijgewerkt. Tot slot kan in de Sprint Review besproken worden wat in een volgende Sprint gedaan kan worden en kan de totaalplanning over de Sprints heen besproken worden.

  • De Sprint retrospective wordt direct na de Sprint Review gehouden en duurt voor een Sprint van een maand maximaal drie uur. Het doel van de Sprint Retrospctive is om te kijken wat goed ging en wat beter kan tijdens de afgelopen Sprint. Dus om een plan te maken voor verbeteringen voor de volgende Sprint. Om deze reden doet het gehele Scrum Team hieraan mee, maar zijn er geen Stakeholders aanwezig. De Sprint Retrospective is het moment om bijvoorbeeld de "Definition of Done" aan te scherpen, maar ook andere (procedurele) verbeteringen kunnen hier vorm krijgen. Het is niet de bedoeling om hier verbeteringen voor het eindproduct te bespreken, hiervoor is de Sprint Review een geschikter moment.

Deze gebeurtenissen zijn belangrijk om te voorkomen dat er allerlei aanvullende / bilaterale overleggen worden georganiseerd waar vervolgens niet de gewenste personen om tafel zitten. Daarnaast zijn de gebeurtenissen bedoeld om een controle moment in te bouwen. Controle van de product voortgang, de Sprint voortgang, of alles naar wens loopt, etc. Dit om steeds te kunnen blijven verbeteren op zowel het proces als op het resultaat.
Alle gebeurtenissen zijn ge time-boxed, wat inhoudt dat ze een maximale duur hebben. Deze tijd hoort dan ook niet overschreden te worden.

Invullen van het Scrum raamwerk

Naast bovenstaande onderdelen, die gezamenlijk het Scrum raamwerk vormen, is er meer nodig voor het ontwikkelen van complexe producten. Het raamwerk moet ingevuld worden. Zo zegt het Scrum raamwerk bijvoorbeeld niets over hoe de Product Backlog eruit moet zien en over de wijze waarop deze beheerd moet worden.

Er bestaan inmiddels veel Best Practices voor het toepassen van Scrum. Hieronder een aantal voorbeelden:

  • Het proces rondom de Backlog Refinement is niet beschreven. Er is alleen beschreven dat de Product Backlog een lijst moet zijn met Items welke de betreffende functionaliteit beschrijft, de waarde ervan weergeeft en de verwachte capaciteit die nodig is voor de realisatie ervan. De lijst moet worden gesorteerd op waarde, met de hoogste waarde bovenaan. Hoe alle Items op de lijst worden beschreven, ligt niet vast binnen het Scrum raamwerk.
    Voor het beschrijven van Product Backlog Items worden vaak User Stories gebruikt, maar het is ook mogelijk om hier Use Cases voor te gebruiken. Belangrijk is dat de omgeving waarin de Product Backlog wordt beheerd, de gewenste beschrijving volledig ondersteund. Niets werkt vervelender dan de manier van beschrijven te moeten aanpassen aan de omgeving waarin ze worden opgeslagen. Onder meer Jira en Team Foundation Server (TFS) hebben Scrum templates waarmee de Product Backlog beheerd kan worden. Neem voldoende tijd voor de keuze van een dergelijk systeem.

  • Voor het beschrijven van Product Backlog Items kunnen zoals gezegd User Stories worden gebruikt. User stories bestaan uit een beschrijvende zin en worden aangevuld met acceptatie criteria. Een User Story is opgebouwd als:
    Als [rol], wil ik [gewenste functionaliteit], zodat [doel]. Bijvoorbeeld: Als geregistreerde bezoeker, wil ik kunnen inloggen, zodat ik afgeschermde gegevens kan benaderen.
    Hieruit blijkt dat deze functionaliteit alleen beschikbaar hoeft te zijn voor geregistreerde bezoekers, dat er blijkbaar een authenticatie mogelijkheid moet komen, met als doel het ontsluiten van bepaalde afgeschermde gegevens.
    Er zijn alleen nog een aantal zaken niet duidelijk. Deze worden vastgelegd in de acceptatie criteria. Bijvoorbeeld:
    • De credentials moeten versleuteld worden verzonden
    • Registreren van bezoekers staat beschreven in User Story "Registreer bezoeker"
    • Het ontsluiten van de betreffende gegevens staat beschreven in User Story "Ontsluit gegevens"
    • ...
    Na het lezen van de User Story ontstaan er vaak veel vragen. Dit is goed. Deze vragen kunnen beantwoord worden tijdens een Backlog Refinement sessie en vervolgens als acceptatie criterium worden toegevoegd. Daarmee ontstaat een volledige beschrijving van de gewenste functionaliteit. Als het niet mogelijk lijkt om de gewenste functionaliteit in een User Story te beschrijven, is de kans groot dat de granulariteit van het Item te laag is; er is te weinig detail aanwezig, dus het is nog te groot. Opdelen van het Item in meerdere Items kan in dit geval een oplossing zijn.

  • Een andere manier van vastleggen van requirements is het beschrijven in Use Cases, eventueel verder gemodelleerd met UML. Een Use Case bestaat uit een aantal delen:
    • Titel
    • Doel / Rationale
    • Actor
    • Pre condities
    • Standaard scenario / stappenplan
    • Alternatieve scenario (herstel- of faal scenarios)
    • Post condities
    Hieruit blijkt onmiddellijk dat er direct veel meer detail wordt beschreven. Daarnaast kan de Use Case nog worden ondersteund met bijvoorbeeld een Use Case diagram, een Activity diagram, een Sequence diagram, een Klassendiagram, etc.
    Het grote verschil is dat voor Use Cases alles helder moet zijn voordat ze geschreven kunnen worden. User Stories daarentegen kunnen organisch groeien. Er kan eenvoudig een acceptatie criterium worden toegevoegd. Om deze reden ben ik van mening dat User Stories meer Agile zijn dan Use Cases, maar het gebruik van Use Cases is absoluut mogelijk, ook binnen Scrum.

  • Het Scrum raamwerk zegt dat het Development Team verantwoordelijk is voor het aantal Backlog Items dat ze voor een bepaalde Sprint selecteren. Wat niet beschreven is, is de manier waarop dit gebeurt.
    Een mogelijke (en naar mijn idee goede) manier hiervoor is het zogenaamde Planning Poker. Hiervoor hebben alle leden van het Development Team een aantal kaarten met daarop de nummers uit de Fibonacci reeks. Dit is een reeks cijfers beginnend met 0, 1 en vervolgens telkens de som van de twee voorgaande cijfers. Dus: 0, 1, (1,) 2, 3, 5, 8, 13, etc. Bij Scrum poker kaarten wordt de reeks meestal aangevuld met de waarden 20, 40 en 100.
    De nummers staan voor de inspanning (in eenheden, niet per se in uren) die nodig is om het Item te realiseren. Ieder Development Team lid bedenkt hoeveel inspanning nodig is en pakt de eerst hogere kaart. Als iedereen een kaart heeft getrokken, worden de kaarten gezamenlijk open neergelegd. Alleen de leden met afwijkende (naar boven of beneden) lichten toe waarom ze deze keuze hebben gemaakt. Op deze manier kan snel tot een pragmatische inschatting worden gekomen.


  • In de Daily Scrum wordt ook de voortgang van de uitgevoerde Items bijgehouden. Dit wordt vaak gedaan op een Scrum Board. Een Scrum Board kan digitaal zijn; zelf vind ik een fysiek bord prettiger. Het Scrum board bestaat uit minimaal vier kolommen, waarin op Post-its de Items en taken worden bijgehouden:
    • De Sprint Backlog Items
    • De "To Do" taken die hier per Item uit voortkomen
    • De "In Progress" taken waar momenteel aan gewerkt wordt
    • De "Done" taken die uitgevoerd zijn.
    Op basis van dit overzicht kan snel worden gezien welke Items inmiddels zijn afgerond. Ook staat het Sprint Doel ergens op het Scrum Board vermeld, om iedereen hieraan te herinneren.

  • Om de planning nog beter inzichtelijk te maken, kan een Burn Down Chart worden bijgehouden. De Burn Down Chart is een grafiek waarbij op de verticale Y-as de totale inspanning (eenheden) voor de huidige Sprint staat, en op de horizontale X-as staat het aantal dagen in de Sprint. Op dag 1 wordt er een punt gezet bij de totale inspanning die is gepland voor de Sprint, en bij de laatste dag wordt er een punt gezet op de horizontale as (resterende inspanning = 0). Tussen deze twee punten wordt een lijn getrokken, welke de ideale Burn Down lijn weergeeft.
    Elke dag wordt nu tijdens de Daily Scrum een punt gezet bij de totale inspanning nodig voor de resterende (nog niet afgeronde) Items. Hiermee wordt de gerealiseerde Burn Down getoond. Als deze lijn boven de ideaal lijn zit is er achterstand, als hij eronder komt is er voorsprong.

 

Contact

 

ITSforYou
Smeesteeg 21
8081 EM  Elburg

U kunt mij bereiken op 06 - 109 15 717 of via info@itsforyou.nl.

Linkedin profiel: www.linkedin.com/in/itsforyou.
ITSforYou is ingeschreven bij de Kamer van Koophandel onder nummer: 08071521.

John Baijens

Op alle leveringen zijn de algemene voorwaarden van toepassing