De toegevoegde waarde van een planningstool bij werken met Scrum.
Bij het ontwikkelen van software is Scrum niet meer weg te denken. Het is een succesvolle methode die projecten fundamenteel anders organiseert. De methode is wars van alle traditionele methoden en technieken rond het begroten, plannen en rapporteren van projecten. Is een planningstool nodig bij een Scrum-project? Dat gaan we in deze blog nader bekijken.
Planning in een Scrum project lijkt overbodig, want met Scrum plan je namelijk mensen fulltime op projecten. Verder worden alle verantwoordelijkheden zo veel mogelijk bij het projectteam neergelegd en is er een minimum aan meetinstrumenten en rapportage. Heel veel informatie wordt ‘analoog’ tijdens korte 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, dat geldt ook bij Scrum. Daarnaast kan een planningstool juist helpen bij een overkoepelende capaciteitsplanning over alle projecten en activiteiten heen. Tot slot kan een planningstool uitstekend de performance meten en deze vergelijken met andere projecten. Zo kan je van voltooide projecten 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, een 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 drie. De lengte van een Sprint en het aantal Sprints zal sterk afhangen van de omvang van de User Stories in Story 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 vijf tot negen 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 Story 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? Je bepaalt je ideale teamgrootte en de deadline door te kijken naar de hoeveelheid Sprints dat het projectteam nodig heeft om de User Stories af te werken. Als je het zo bekijkt dan heb je met Scrum helemaal geen planningstool nodig. Is dat ook echt zo?
2. Een planningstool blijft bij Scrum nodig
Inzet plannen bij Scrum is eenvoudig en nodig
Resource planning is altijd de achilleshiel van project planning geweest. Heb je eindelijk je project in detail gepland, begint je project opeens te schuiven. Dramatisch, want andere projecten maken tussendoor ook gebruik van jouw medewerkers. De resource planning valt dan als een kaartenhuis in elkaar.
Wat dat betreft is Scrum een zege, want Scrum propageert fulltime inzet van projectmedewerkers. Dat maakt het een stuk eenvoudiger om te plannen, omdat je medewerkers voor een paar maanden op een project kunt wegzetten. Dat geeft rust in de planning, want er is minder dynamiek. Toch zijn er twee aandachtspunten:
- Instroom/werk aan andere projecten;
- Overige afwezigheid.
Instroom/werk aan 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 een dag in de week op een ander (niet-Scrum) project zit of simpelweg operationele activiteiten moet uitvoeren. Dat heb je een planningstool nodig, anders kun je er met Scrum geen rekening mee gehouden.
Met uitzicht op het einde van het project, zullen medewerkers ook op een volgend project worden ingepland. Ook dit wil je tijdelijk inzichtelijk hebben, zodat je op tijd kunt bijsturen als het huidige project toch uitloopt. 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 dus niet vanuit gaan dat je team in elke Sprint hetzelfde aantal Story Points kan wegwerken. Je hebt bijvoorbeeld een planningstool nodig als je goed rekening wil houden met de overige afwezigheid, wanneer je in Scrum een Sprint gaat plannen. Een andere oplossing is een kleiner aantal Story Points of je zorgt voor vervanging, waardoor je wel op volle sterkte verder kan.
3. Met Scrum de performance meten, dan heb je een planningstool nodig.
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 heb je met Scrum een planningstool nodig om goed inzicht te krijgen van de totale portfolio van projecten. Welke projecten doen het goed en welke minder? Dat geeft het management focus 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 is een planningstool niet nodig. 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, is een planningstool absoluut nodig. 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.
