Voordelen om Timewax te gebruiken voor Scrum projecten:
- Één projectadministratie tezamen met niet-Scrum projecten
- Visuele weergave van alle projecten en Sprints
- Integrale capaciteitsplanning inclusief overig werk/afwezigheid
- Samenwerken aan User stories met behulp van Taken
- Inzicht in benodigde uren vs. beschikbare uren per Sprint
- Inzicht in Velocity projectteam (begroot vs. werkelijk benodigd)
Met het werken volgens Scrum verandert de manier waarop je projecten en medewerkers plant. In dit artikel lichten we toe hoe je Timewax kunt gebruiken als je met Scrum werkt. We behandelen achtereenvolgens:
- Opzet project
- Story points vs. begrote uren
- Taken
- Plannen van Sprints
- Plannen van medewerkers
- Rapportage
In dit artikel gaan we er vanuit dat typische termen uit Scrum, zoals Sprints, User stories en Product backlog, bekende termen zijn. De termen verhouden zich als volgt in Timewax:
| Scrum term | Timewax term | Timewax functie |
| Sprint | (Hoofd)activiteit | Project |
| User story | Activiteit | Project |
| Story points | Begrote uren | Project |
| Product backlog | (Hoofd)activiteit | Project |
| Bug | Activiteit | Project |
| Taak | Taak | Taken |
1. Opzet project
Voor elk project maak je in Timewax een project aan. In Timewax kun je een project onderverdelen in activiteiten. Bovendien kun je een hiërarchie van activiteiten aanleggen. Hier maken we gebruik van om de Sprints en User stories te definiëren.
Specifiek voor de Product backlog items maken we ook een activiteit aan. De structuur kan er dan als volgt uitzien:
Scrum project X
– Product backlog
- User story 01
- User story 03
- User story 06
- User story ….
– Sprint 1
- User Story 02
- User Story 04
- User Story 05
- Sprint 1 resource planning
– Sprint 2
- User Story 07
- User Story 12
- User Story 15
- Bug A
- Sprint 2 resource planning
– Sprint 3
– Sprint …..
Bij aanvang van het project bevinden alle User stories zich onder de Product backlog. Hieronder worden ook alle User stories uitgewerkt en begroot in aantal benodigde uren.
Op het moment dat er een Sprint wordt gepland, worden de betreffende User stories verplaatst vanuit de Product backlog naar de betreffende Sprint. Naast User stories kunnen in Sprints ook Bugs worden ondergebracht uit vorige Sprints, die in de aankomende Sprint moeten worden opgelost.
In elke Sprint bevindt zich ook een activiteit ‘Sprint Resource planning’. Dit is geen Scrum-element, maar puur een administratieve activiteit in elke Sprint om medewerkers op te plannen in het Planbord. In Scrum worden namelijk medewerkers niet ingepland op User stories. In Timewax willen we medewerkers wel per Sprint plannen, zodat we ook in rapportage kunnen zien of we voldoende capaciteit hebben gepland om de User stories te realiseren.
Voor de opzet van User stories is het van belang om ze aan te merken voor de ‘Gantt Chart’ en niet voor ‘Resource boekingen’. Bij de administratieve activiteit voor de resource planning doen we dit precies andersom.
2. Story points vs. begrote uren
In Scrum worden ten behoeve van de planning User stories uitgedrukt in Story points. De kleinste story krijgt 2 punten. Met planning poker wordt de relatieve waarde van de andere User stories bepaald. Van een aantal User stories wordt berekend wat de benodigde uren zijn. Daarmee wordt vastgesteld hoeveel uur benodigd zijn om een Story point te realiseren.
In Timewax kunnen geen Story points worden vastgelegd bij de User stories. Bij elke User story dient het begrote aantal uren te worden vastgelegd. Volgens Scrum krijgen Bugs geen Story points. Het begrote aantal uren van Bugs is daarmee 0.
Hieronder zie je hoe je per User story het aantal begrote uren kunt ingeven. Je kunt ook een uurtarief meegeven, zodat de User story ook een financiële begrote waarde krijgt. Dit kan in rapportages gebruikt worden.
3. Taken
Indien gewenst kunnen volgens Scrum de User stories ook weer verder uitgesplitst worden in Taken. Per User story zijn er maximaal 5 Taken.
In Timewax kun je hiervoor de functie Taken gebruiken. Taken kun je koppelen aan een User story en aan een medewerker die verantwoordelijk is voor de uitvoering. Je kunt met meerdere gebruikers een Taak bewerken en berichten plaatsen.
Bij updates van Taken en berichten, kun je als actiehouder van de Taak een e-mail bericht ontvangen. Dit kun je bij je persoonlijke instellingen configureren.
In de Taken view kun je weergaven toevoegen om specifieke overzichten te maken van alle Taken of een deel hiervan. Op deze manier kun je gezamenlijk met je projectteam de Taken beheren.
4. Plannen van Sprints
Sprints hebben gedurende het project een vaste lengte, bijvoorbeeld 3 weken. Met de Gantt Chart functie kun je in Timewax visueel de project planning weergeven.
Hierbij een voorbeeld.
In dit voorbeeld zie je dat de User stories ook dezelfde doorlooptijd hebben als de Sprint zelf. Volgens Scrum is het namelijk niet de bedoeling om User stories te gaan plannen met een start- en einddatum. Het projectteam krijgt zelf de vrijheid om gedurende de Sprint aan de User stories te werken.
Je kunt in de Gantt Chart met kleuren werken om bijvoorbeeld het onderscheid te maken in afgeronde User stories en Bugs.
5. Plannen van medewerkers
Volgens Scrum wordt uitsluitend gewerkt met ‘dedicated’ medewerkers. Dit betekent dat medewerkers niet aan meerdere projecten tegelijkertijd werken, maar fulltime beschikbaar zijn voor één project. In de praktijk is dat niet altijd haalbaar. Zo komt het voor dat medewerkers bijvoorbeeld een hele of halve dag per week nog vrij moeten houden voor andere opdrachten of operationeel werk.
Los daarvan blijft de behoefte bestaan om overige afwezigheid zoals ziek, vakantie en training te kunnen registeren. Resource planning wordt weliswaar eenvoudiger, maar zal nog steeds nodig zijn om de bezetting in projecten en op afdelingen te bewaken.
In Timewax gebruik je het planbord voor het plannen van de medewerkers (resources). Voor een organisatie die met Scrum werkt, kan dit er als volgt uitzien.
Je plant medewerkers voor volledige volledige weken in op een Sprint, in dit voorbeeld per 3 weken. In het voorbeeld is ook inzichtelijk dat een medewerker met vakantie gaat (blauwe boekingen) en dat hij vervangen wordt door een andere medewerker.
6. Rapportage
Met de functie Bezetting kun je voor je gehele organisatie of per afdeling/functie de bezetting analyseren. Omdat je medewerkers gewoon plant op de projecten via Sprints enerzijds en overige opdrachten en afwezigheid anderzijds, krijg je een accuraat beeld van de werkdruk. Sprints hebben een vast karakter, dus je kunt redelijk ver vooruit kijken. Wat dat betreft geeft Scrum meer ‘rust’ en ‘stabiliteit’ in de planning.
Met de functie Opvragingen kun je ook inzichtelijk maken of de bezetting in je project op orde is. Aan de ene kant heb je namelijk per Sprint begrote uren op basis van de User stories. Aan de andere kant heb je medewerkers ingepland op de administratieve activiteit per Sprint voor resource planning. Zo kun je dus zien of de capaciteit in je team voldoende is om de User stories te realiseren.
Zie hieronder een voorbeeld van een opvraging met de functie Opvragingen.
In dit voorbeeld zie je dat Sprint 1 in totaal 108 uren tekort komt om de User stories te realiseren. Dit kan dus aanleiding zijn om andere User stories te selecteren of om capaciteit bij te plannen. Bij Sprint 2 zie je dat je 42 uur over hebt ten opzichte van van wat je verwacht nodig te hebben.
Verder kun je desgewenst ook de werkelijk gemaakte uren gaan registeren. Dit kan plaatsvinden op het niveau van de User stories. Zo kun je achteraf analyseren of de begrote uren (op basis van Story points) voor iedere User Story toereikend zijn ingeschat. Op die manier kun je ook beoordelen of de Velocity van het projectteam toeneemt.
Tijdschrijven hoort oorspronkelijk niet bij de Scrum-gedachte. Toch zijn veel dienstverleners nog gebonden aan tijdschrijven, omdat niet alle projecten volgens Scrum worden uitgevoerd. Voor deze projecten is een (traditionele) registratie van uren vereist om het budget te kunnen bewaken en eventueel te factureren voor projecten op basis van nacalculatie.