Tijdens mijn introductie bij Sogyo ben ik voor het eerst in aanraking gekomen met 'SCRUM', een simpele methode voor software ontwikkelaars om te plannen en zich aan planningen te houden en voor betrokkenen om de voortgang in de gaten te houden.
Het plaatje wat erbij hoort ziet er complex uit, maar is verder best logisch als je dit naast het volledige schema van PRINCE2 houdt.

Waar komt het op neer?
Het proces waar het bij scrum om gaat is vrij simpel, er is een groep mensen: het 'ontwikkel' team, een scrum master en een product owner. Het ontwikkel team kan overigens ook designers, copywriters en gebruikers bevatten mocht dit mogelijk/nodig zijn.
Deze mensen bepalen in overleg wat er gewenst is (indien de product owner niet de klant is, is het aan te raden de klant er ook bij te betrekken), waarna deze wensen uitgewerkt worden in user stories, korte zinnen die uitleggen wie iets wil kunnen doen met de software, wat deze persoon wil doen en wat deze persoon met de actie wil berijken.
Uit deze user stories worden vervolgens de benodigde onderdelen bepaald die gemaakt/uitgewerkt zullen moeten worden.

Planning poker
Als er uitgewerkt is welke onderdelen er dus moeten komen, komt het punt dat er bepaald dient te worden hoe veel moeite ieder punt kost om te berijken. Hiervoor wordt vaak planning poker gebruikt, dit is een simpele manier om aan te geven hoeveel moeite iedereen denkt dat een specifiek onderdeel van de planning zal gaan kosten. Iedere deelnemer heeft een stapeltje kaarten met 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 en ?. Bij het eerste item wordt een gemiddelde waarde aangenomen, zeg 8. Bij de daaropvolgende items kiest een ieder voor zich welke moeite hij/zij denkt dat het item gaat kosten in verhouding tot het eerste item. Ieder teamlid laat tegelijk zijn/haar gekozen kaart zien en vervolgens kan er gediscussieerd worden over waarom iemand denkt dat het meer of minder moeite kost dan iemand anders gedacht heeft, om zo tot een realistische inschatting te komen.
Op deze manier ontstaat een gewogen lijst van onderdelen die gemaakt moeten worden, de zogenaamde product backlog. Hierna kan men beginnen aan de eerste 'sprint'.

De eerste sprint
Een sprint is een periode van 1 tot 4 weken waarin er wordt gewerkt aan het produkt. Iedere sprint dient een werkend produkt op te leveren. Aan het begin van de sprint wordt bepaald welke onderdelen van de produkt backlog in de huidige sprint worden opgepakt, in volgorde van prioriteit. Dit is de sprint backlog. De prioriteit wordt in een overleg van het team en de product-owner bepaald.
Nadat er vastgesteld is welke onderdelen er in de sprint opgepakt worden, kan het team aan de slag. De lijst met items in de sprint-backlog staat vast gedurende de gehele sprint, op deze manier blijft er duidelijk wat aan het eind van de sprint verwacht kan worden.
Het team gaat nu aan de slag met deze punten en houdt ook bij hoever de punten waar hij/zij aan werkt zijn gevorderd.

De daily scrum
Iedere dag, aan het begin van de dag komen de ontwikkelaars kort bij elkaar om te bespreken wat iedereen de dag ervoor gedaan heeft, wat er vandaag gaat gebeuren en welke problemen er zijn geweest. Deze meeting is vooral een onderlinge update en houdt de ontwikkelaars betrokken bij het project.

De burn-down-chart
De burn-down-chart is een grafiek die gegenereerd wordt op basis van de workload uit de sprint backlog, afhankelijk van de weging die verkregen is bij het plannings poker. In deze grafiek staat een lijn die van de volledige workload gedurende de tijdsduur van de sprint naar nul gaat (een schuine lijn dus), de ideale burn-down. Verder staat in deze grafiek ook hoeveel punten er nog open staan op ieder moment. Naarmate de tijd vorderd zal ook deze lijn naar nul gaan, loopt de lijn boven de ideale burn-down, dan loopt het team achter op planning, loopt de lijn er onder, dan loopt het team voor.
Deze burn-down--chart, in combinatie met de sprint-backlog geeft een goed beeld van hoe de ontwikkeling loopt en wat er al af is.

Einde eerste sprint/begin tweede sprint
Aan het einde van de eerste sprint is er een produkt wat opgeleverd kan worden, hoewel het meestal slechts beperkte functionaliteit heeft. Op dit moment kunnen er aanpassingen gedaan worden in de product-backlog en kan er opnieuw middels planning poker een weging gehangen worden aan de backlog items. De tweede sprint gaat nu verder zoals de eerste sprint, maar deze keer kan, met behulp van de uiteindelijke burn-down rate van sprint 1 een betere schatting afgegeven worden van de capaciteit voor sprint 2 en kan eventueel het ontwikkel team uitgebreid worden, mocht dat nodig zijn.

Iedere hieropvolgende sprint zal nu vergelijkbaar verlopen als de tweede. Gezien er nu data is over de capaciteit van het team, zal er een realistische planning afgegeven kunnen worden voor de sprint.