Scrum: geen planningstool meer nodig?

De toegevoegde waarde van een planningstool bij Scrum
Scrum: geen planningstool meer nodig?

Bij het ontwikkelen van software is Scrum niet meer weg te denken. Het is een succesvolle methode die op een fundamenteel andere manier projecten organiseert. De methode is wars van alle traditionele methoden en technieken rond het begroten, plannen en rapporteren rondom projecten. Biedt een planningstool dan geen toegevoegde waarde bij dit Scrum projecten? Dat gaan we in deze blog nader bekijken.

Planning in een Scrum project lijkt overbodig. Je plant namelijk mensen dedicated (fulltime) op projecten. Verder worden alle verantwoordelijkheden zo laag mogelijk bij het projectteam neergelegd en is er een minimum aan meetinstrumenten en rapportage. Heel veel informatie wordt ‘analoog’ tijdens vergaderingen (stand ups) uitgewisseld en op fysieke borden bijgehouden.

Heeft een planningstool dan niets te bieden? Zeker wel. Aan de basis van elk project ligt ten slotte een begroting en een planning ten grondslag, zo ook bij Scrum. Daarnaast kan een planningstool juist helpen bij een integrale capaciteitsplanning over alle projecten en activiteiten heen. Tot slot kan een planningstool uitstekend de performance meten en vergelijken met andere projecten om hier vervolgens van te leren.


1. Scrum plant wel degelijk, alleen anders

Het begroten van User Stories

In Scrum worden User Stories begroot in Story Points in plaats van uren. De basis van een Story Point is echter nog steeds aantallen uren. Alle User Stories worden relatief ten opzichte van elkaar begroot. Dit wordt gedaan aan de hand van de techniek Planning Poker. Uiteindelijk resulteert dit in één grote verzameling (Product Backlog) van User Stories die allemaal een begroting hebben.

Het bepalen van de doorlooptijd op basis van Sprints

Vervolgens worden er Sprints gepland. Een Sprint is een periode van een vast aantal weken, bijvoorbeeld 3 weken. De lengte van een Sprint en het aantal Sprints zal sterk afhangen van de omvang van de User Stories in User Points (uren) en de beschikbare capaciteit van het projectteam. Als de User Stories gemiddeld veel Story Points omvatten, dan zul je sneller een langere Sprint nodig hebben.

Het samenstellen van het team (de capaciteit)

Een Scrum team bestaat uit 5 tot 9 medewerkers. Je stelt het team samen naar aanleiding van de gewenste kennis en vaardigheden, maar ook de benodigde capaciteit en de deadline spelen een rol. Staat de deadline vast? Dan kun je op basis van het aantal User Points precies de benodigde capaciteit per week/Sprint uitrekenen. Dat bepaalt hoeveel medewerkers je in je team nodig hebt.

Werk je niet met een specifieke deadline voor het project? Dan bepaal je je ideale teamgrootte en wordt de deadline automatisch bepaald door het aantal Sprints dat het projectteam nodig heeft om de User Stories af te werken.


2. Resource planning blijft cruciaal

Inzet plannen bij Scrum is eenvoudig

Resource planning is altijd de achilles hiel geweest van project planning. Had je eindelijk je project in detail gepland, begon je project opeens te schuiven. Dramatisch, want andere projecten maakten tussendoor ook nog gebruik van jouw medewerkers. De resource planning valt dan als een kaartenhuis in elkaar.

Wat dat betreft is Scrum een zege, want Scrum propageert dedicated inzet (fulltime) van projectmedewerkers. Dat maakt het een stuk eenvoudiger om te plannen, omdat je medewerkers meteen voor een paar maanden op een project kunt wegzetten. Dat geeft rust in de planning, er is minder dynamiek. Toch zijn er nog wel 2 aandachtspunten: instroom/werk op andere projecten en overige afwezigheid.

Instroom/werk op andere projecten

Fulltime beschikbaarheid van medewerkers op een project is ideaal, maar niet altijd haalbaar. In de praktijk kan blijken dat een medewerker toch echt één dag in de week op een ander (niet-Scrum) project zit of simpelweg operationele activiteiten moet uitvoeren. Dat moet gepland worden, anders kun je er geen rekening mee gehouden.

Met uitzicht op het einde van het project, zullen medewerkers ook weer op een volgend project worden ingepland. Ook dit wil je tijdelijk inzichtelijk hebben, zodat je op tijd kunt bijsturen als zich bijvoorbeeld meerwerk aandient. Het zou heel vervelend zijn als je beloften maakt naar de klant die je niet kunt waarmaken, omdat je projectteam gaat uitstromen.

Overige afwezigheid

Project of niet, medewerkers gaan op vakantie, worden ziek en zullen ook wel eens een training volgen. Dit kan een behoorlijke impact hebben op een Sprint. Je kan er niet vanuit gaan dat je team in elke Sprint hetzelfde aantal User Points kan wegwerken. Met inzicht in de capaciteitsplanning kun je rekening houden met de overige afwezigheid bij het plannen van een Sprint. Je selecteert simpelweg een kleiner totaal van User Points of zorgt voor vervanging, waardoor je wel op volle sterkte verder kan.


3. Performance meten: de sleutel tot leren

Scrum kijkt alleen vooruit

Om de voortgang te meten en bij te sturen, werkt Scrum met een Burndown Chart. Hierin wordt op grafische wijze het aantal uur/Story Points in de tijd uitgezet met een (ideaal) lineair verloop. Vervolgens wordt de daadwerkelijke voortgang hierop afgezet op basis van de nog te realiseren uren/Story Points. Bij het meten van de voortgang op moment X wordt alleen maar gekeken naar wat er vanaf moment X tot het einde van de Sprint nog gerealiseerd moet worden. Is het verleden dan niet interessant?

Tijdschrijven is dood, lang leve het tijdschrijven!

Aan tijdschrijven hebben ze bij Scrum een broertje dood. Dat is terugkijken naar het verleden en daar doen ze niet aan. Ze vinden dat het een verkeerde mindset bij medewerkers teweegbrengt, doordat ze zich als het ware “aan het verantwoorden zijn”. Dit zou verkeerd gedrag stimuleren. Een argument waar zeker wat voor te zeggen is.

Echter, door te registreren hoeveel uren je aan een User Story hebt besteed, kun je daarentegen een exacte vergelijking maken met de begroting van die User Story. Daarmee krijg je inzichtelijk hoe realistisch je begroting was en dat is heel waardevol, want op die manier leren we. Meten is weten en daarmee kunnen we volgende projecten en User Stories weer beter inschatten.

Rapportage over projecten heen

Tot slot kan een planningstool goede inzichten geven in de totale portfolio van projecten. Welke projecten doen het goed en welke minder? Dat geeft het management focus op welke projecten ze nader in de gaten moeten houden.

Wat de performance van een Scrum team betreft: volgens Scrum wordt een goed functionerend team bij elkaar gehouden voor de uitvoering van volgende projecten. In de cijfers willen we dat dan ook terug zien. Wordt de performance van een team beter? Of in Scrum-termen: neemt de Velocity van het projectteam toe? Omdat een planningstool de historie vasthoudt, kan het goed in deze informatie voorzien.


Conclusie

Als je over slechts één team beschikt dat volgens Scrum werkt, dan heeft een planningstool niet zo veel zin. Het is immers steeds hetzelfde team dat sequentieel projecten wegwerkt. Natuurlijk is het interessant om de performance te meten, maar een planningstool zal hier geen bittere noodzaak zijn.

Maar bij een dienstverlener met meerdere Scrum teams en medewerkers die ook nog aan andere (traditionele) projecten en activiteiten werken, heeft een planningstool absolute meerwaarde. Je hebt tenslotte een grotere pool van medewerkers die continu in- en uitstromen op projecten. Grip op de capaciteitsplanning is dan essentieel, omdat anders de uitvoerbaarheid van projecten gevaar begint te lopen.

Voor Timewax zelf hebben we uitgewerkt hoe je de Scrum methode in Timewax kunt vormgeven. Zie hiervoor dit support artikel. Hierin geven we heel concreet en stap voor stap aan hoe je om dient te gaan met de inrichting, het begroten, plannen en de rapportage rond Scrum projecten.

Vragen of opmerkingen naar aanleiding van dit artikel? Neem contact op met Timewax.


Founder
Mark de Jong
Mark is directeur Sales & Marketing bij Timewax. Hij heeft een achtergrond als project- en resourcemanager bij o.a. PricewaterhouseCoopers Management Consultants met expertise op het gebied van Professional Service Automation (PSA).
Optin Architect