Toegezegd werk wint van onzeker werk
Tegenover een experiment staat een feature waar iemand op rekent. Die afweging valt vrijwel altijd dezelfde kant op, niet omdat het experiment slecht is maar omdat de kosten zeker zijn en de opbrengst niet.
Roadmap vol, geen plek voor experimenten
De roadmap ligt vast en elk experiment kost capaciteit die al is toegezegd. Ideeën die de moeite waard lijken belanden op een lijst die alleen maar langer wordt. Een prototype dat buiten je sprintcapaciteit om wordt gemaakt, geeft je iets om over te beslissen zonder dat je iets hoeft te schrappen.
01
/
04
Waarom experimenten altijd verliezen
Drie mechanismen die goede ideeën van de roadmap houden.
De inschatting is te vaag om in te plannen
Een idee zonder uitgewerkte scope krijgt geen betrouwbare schatting. Wat volgt is een ruime marge, en die marge maakt het te duur voor iets dat nog getoetst moet worden.
Er is geen moment om het te bespreken
Refinement gaat over wat al besloten is. Een idee dat nog niet in de backlog staat, komt daar zelden vanzelf op, ook als iedereen het interessant vindt.
02
/
04
Wat wel en niet in een werkdag past
De beperking dwingt tot een keuze, en dat is precies wat het bruikbaar maakt.
Wat we in een dag doen
- De kern-userflow klikbaar maken, zonder je team erbij nodig te hebben.
- De aannames zichtbaar maken die anders in een schatting verdwijnen.
- Een deelbare URL opleveren voor refinement of stuurgroep.
- Benoemen welk deel de meeste onzekerheid bevat.
- Vastleggen wat er voor een echte bouw nodig zou zijn.
Wat er niet in past
- Werk dat rechtstreeks in jullie codebase landt.
- Een schatting die je als planning kunt gebruiken.
- Integratie met bestaande services of data.
- Een technisch ontwerp dat je team kan overnemen.
- Een besluit over prioriteit, dat blijft bij jullie.
03
/
04
Hoe zo'n werkdag verloopt
Je team merkt er weinig van. Jij bent nodig op de momenten dat er een keuze ligt.
-
09:00
Context en gebruiker
Welk probleem los je op en voor wie? We bepalen wie het prototype straks moet overtuigen, meestal je stakeholders of stuurgroep.
-
10:00
De kern-userflow
Welk pad vertelt het verhaal? We kiezen de ene flow die klikbaar wordt en schrijven de rest op als vervolg.
-
11:30
De onzekerheid isoleren
Welk deel is precies het experiment? Dat maken we werkend, de rest mag statisch blijven.
-
13:30
Bouwen
We zetten de flow om in werkende schermen, met tekst en data die herkenbaar zijn voor jullie product.
-
15:30
Doorlopen en aanscherpen
We lopen het door met de vraag waar een stakeholder zou afhaken, en passen aan waar dat nodig is.
-
17:00
Overdracht
Je krijgt de werkende URL, een korte walkthrough en de aannames op een rij.
04
/
04
Wat het in de planning verandert
Niet de roadmap openbreken, maar de volgende ronde beter voorbereiden.
Een idee met een werkend prototype is een ander agendapunt dan een idee zonder. De discussie verschuift van of we hier tijd aan zouden moeten besteden naar wat het precies zou kosten om dit af te maken. Dat tweede gesprek kun je met je team voeren, en de schatting die eruit komt is bruikbaar.
Het werkt ook andersom. Blijkt uit reacties dat het idee minder oplevert dan gedacht, dan gaat het van de lijst zonder dat het ooit sprintcapaciteit heeft gekost. Dat is een goedkope manier om een backlog op te schonen.
Voor product owners is er nog een praktisch voordeel: je kunt laten zien dat er over is nagedacht zonder dat je iets hebt hoeven schrappen. Dat maakt het makkelijker om er in de volgende planningsronde ruimte voor te vragen.
Zit het knelpunt eerder bij mensen dan bij planning, dan sluit geen development-capaciteit in huis beter aan. Moet het budget nog rond komen, kijk dan bij geen budget voor een volledig traject. En om de scope scherp te krijgen voordat je begint, is er de scope-slicer.
05
/
05
Veelgestelde vragen
Hoeveel tijd kost dit mijn team?
Een intake vooraf en een terugkoppeling achteraf. Tijdens de dag zelf is er iemand nodig die knopen kan doorhakken, meestal de product owner. Developers zijn niet nodig, tenzij er een bestaand systeem in het spel is.
Komt dit werk in onze codebase terecht?
Nee. Het prototype staat los en is bedoeld om een vraag te beantwoorden. Als het idee doorgaat, bouwt je team het zelf op de manier die bij jullie architectuur past.
Kan ik dit gebruiken om budget of capaciteit te vragen?
Dat is een van de meest voorkomende redenen. Een werkend voorbeeld maakt de vraag concreet, waardoor de discussie over de omvang gaat in plaats van over het nut.
Wat als het prototype vragen oproept die we niet kunnen beantwoorden?
Dan heb je die vragen nu in plaats van halverwege een bouwtraject. Openstaande punten leggen we vast, zodat ze meegaan naar de refinement in plaats van te verdwijnen.
Levert dit een schatting op die we kunnen inplannen?
Niet direct. Wat je krijgt is een scherper beeld van wat het idee inhoudt, en dat maakt de schatting van je eigen team betrouwbaarder. De planning blijft jullie werk.
Wij werken niet met sprints. Werkt dit dan ook?
Ja. Het knelpunt is meestal niet de methode maar het feit dat capaciteit al belegd is. Dat probleem is hetzelfde of je nu in sprints, kanban of vaste releases werkt.
