slim
samen
werken

Wat is een Timebox?

Een Timebox is een belangrijke, waardevolle werkafspraak die wordt toegepast door Agile teams. Een timebox is een tijdslimiet die aan een specifieke activiteit wordt gesteld. Het gaat daarbij altijd om activiteiten als werkprocessen, vergaderingen, of bijeenkomsten. De maximale hoeveelheid daaraan te besteden tijd wordt met de timebox gelimiteerd. Er is overigens geen afspraak over de minimum hoeveelheid tijd.  Immers, hoe minder tijd iets kost hoe beter, zolang je het doel van de activiteit maar behaalt.

Time_box

Een Timebox, waarom?

In een agile organisatie worden projecten ook getimeboxed.  De totale hoeveelheid beschikbare tijd staat vast en is dus beperkt. De scope van een Agile project daarentegen staat niet vast, deze wordt voor een deel gedurende het project pas bekend. Bij traditioneel projectmanagement werkt dat precies omgekeerd. Daar ligt de scope van tevoren al vast en blijkt tijd telkens weer een rekbaar begrip. De reden dat de scope niet van tevoren vast kan staan, is complexiteit. Complexiteit ontstaat bijvoorbeeld door een dynamische omgeving die constant aan verandering onderhevig is en veel verschillende stakeholders met verschillende wensen en behoeften. In een Agile cultuur onderkent men deze complexiteit en de bijkomende onzekerheid als realiteit. Het tackelen van complexiteit is voor Agile teams een belangrijke reden voor het timeboxen van activiteiten.

Complexiteit

Agile teams knippen een complex project op in kleine taken of activiteiten, kortom “werk”, dat in korte periodes kan worden voltooid. Zo’n periode heeft een vaste duur oftewel: de “timebox”.  Bij Scrum, een agile raamwerk,  noemt men zo’n periode een “Sprint”. Veel Scrum teams kiezen voor een Sprint met een timebox van twee weken. Sprints van één, drie of vier weken komen overigens ook voor.

Voor elke Sprint wordt er een sprintdoel vastgesteld, dat in concrete vorm moet worden opgeleverd.  Feitelijk een klein stukje van het totale project.  Doordat het Sprintdoel klein is gemaakt en de horizon niet verder reikt dan twee weken, kan een team beter prioriteren en focussen. Hierdoor kan het werk binnen één Sprint in concrete vorm worden opgeleverd.  En doordat het concreet is, kan het opgeleverde werk vervolgens worden gevalideerd. Daarmee wordt er op empirische wijze geleerd, kennis en voortschrijdend inzicht vergaard. Zo wordt een team ook wendbaar, omdat het in staat is om steeds aanpassingen te doen op basis van dat voortschrijdend inzicht. En wendbaarheid is noodzakelijk voor het om kunnen gaan met complexiteit.
Agile Complexity

Structurele keuze

De timeboxen van de activiteiten worden door het Agile team vóóraf bepaald. Zo kiest een Scrumteam van tevoren de timebox voor de Sprint en alle bijeenkomsten die onderdeel uitmaken van die sprint.  Het gaat hier om structurele keuzes waaraan het team zich houdt gedurende het hele project. Zodra een redelijke timebox is bepaald, moet deze consistent worden gehandhaafd. Houdt een team zich niet aan de timeboxen, dan zie je dat vaak terug in verminderde discipline, productie en kwaliteit. Ook wordt de samenwerking lastiger tussen de directe omgeving en het team, omdat deze niet op elkaar ingespeeld raken. Een onvoorspelbaar team zorgt voor ruis en daarmee voor meer complexiteit. En dat kan niet de bedoeling zijn.

Voorbeelden van Agile Timeboxes

Er zijn veel verschillende Agile raamwerken en de meeste zijn strak gestructureerd met duidelijke timeboxen. Hieronder enkele voorbeelden van timeboxen zoals ze vooral in Scrum worden toegepast:

  • Sprint

De Sprint is een timebox van een maand of minder waarin het scrumteam de Sprint-doelen vaststelt en behaalt. Een sprint van twee weken is vrij algemeen, maar Sprints van één, drie of vier weken komen ook voor.  Sprints langer dan vier weken zorgen voor te veel complexiteit en daardoor voor meer risico en minder focus binnen het team.

  • Sprint Planning

Bij een Sprint van één maand gaat men voor de Sprint-planning uit van een timebox van 8 uur of minder.  Hoe korter de Sprint, hoe korter de timebox van de Sprint Planning. Een Sprint van drie weken heeft een timebox van maximaal zes uur, een Sprint van twee weken vier uur, etc. Dit zijn maxima, want korter mag altijd.

  • Sprint Retrospectief

De Sprint Retrospectief is een timebox van drie uur of minder voor een sprint van een maand, anderhalf uur voor twee weken, etc.  Dit is een bijeenkomst waarbij het team zichzelf inspecteert en mogelijkheden voor procesverbetering identificeert. Elke Retrospectief kiest het team een of twee verbeteringen die het de volgende sprint zal doorvoeren.

  • Daily Scrum / Daily Stand Up / Dagstart

Een Scrumteam heeft per 24 uur een timebox van 15 minuten voor de Daily Scrum. Deze activiteit gebruikt het team om de dag te plannen, te synchroniseren en eventuele obstakels te identificeren.  Obstakels die het team belemmeren het Sprintdoel te behalen moeten zo snel mogelijk worden opgelost.

  • Sprint Review

De Sprint Review is een timebox van vier uur of minder voor Sprints van één maand, twee uur of minder voor twee weken, etc. Tijdens de Sprint Review wordt het werk dat tijdens de sprint is opgeleverd, gedemonstreerd en geïnspecteerd. De kennis en voortschrijdend inzicht worden direct gebruikt om vooruit te kijken en plannen te maken voor de volgende Sprint.

Enthousiast geworden om meer te weten te komen over Timeboxing in Agile? Of over Scrum in zijn algemeen. Volg dan een van onze Scrum trainingen. Neem contact met ons op om vrijblijvend telefonisch kennis te maken met een van onze ervaren Agile trainers & coaches. We beantwoorden je vragen graag, bel 020 2614 195.

Ook interessant:

Over de auteur: Frank Verhelst

Frank is Agile Coach en Scrum trainer. Hij helpt teams met het aanleren van de routines rond Scrum en Kanban. Vanuit ‘Voordoen, na- doen, zelf doen’ is het de bedoeling de teams zo snel mogelijk op eigen kracht op gang te brengen. Frank is een gepassioneerd trainer; energie, inspireren en doen! kenmerken zijn stijl. Naast de Scrum methode heeft hij ook ervaring met Design Thinking en Design Sprints en besteedt hij veel aandacht aan het schrijven van goede User Stories.