Het opsplitsen van user stories die niet in een sprint passen

Een verhaal waarvan u de omvang niet kunt inschatten, is meestal een verhaal dat nog niet klaar is voor publicatie. Hoe weet u wanneer u het moet opsplitsen, welke scheidingslijnen tot publiceerbare delen leiden en welke slechts een schijnoplossing bieden?

Het opsplitsen van een user story houdt in dat u één verhaal dat te groot is, opsplitst in kleinere verhalen die elk nog steeds iets opleveren waar een gebruiker iets aan heeft. Een verhaal dat u niet kunt inschatten, is meestal een verhaal dat u nog niet kunt opleveren — en door het op te splitsen kunt u het weer op het bord zetten.

De meeste gesprekken waarin wordt gezegd „dit kunnen we niet inschatten” zijn in feite verkapte gesprekken over het opsplitsen van taken. Het team kampt niet met een probleem op het gebied van cijfers en inspanning; het probleem is dat er te veel onbekende factoren zijn. Door taken op te splitsen worden de onbekende factoren verminderd, totdat het verhaal de vorm krijgt van werk dat al eerder is uitgevoerd — en de schattingen naar elkaar toe groeien.

Wanneer moet men stoppen met schatten en beginnen met opsplitsen?

Een verhaal dat niet in een sprint past, is geen kwestie van omvang, maar van vorm. Let op de signalen:

  • Het team stemt op 13 en 20, en blijft vervolgens opnieuw stemmen om tot overeenstemming te komen in plaats van verdeeld te raken.
  • “Dat hangt ervan af” is het antwoord op meer dan een paar van de verduidelijkingsvragen.
  • Het verhaal strekt zich uit over het werkgebied van meer dan één team.
  • Voor de status „Voltooid“ zijn meerdere implementaties vereist.
  • U kunt het in twee zinnen beschrijven, maar niet in twee acceptatiecriteria.

Als u er toch mee doorgaat, besteedt het team de sprint aan pogingen om het af te ronden en wordt het resterende werk doorgeschoven — met slechte resultaten, omdat het doorgeschoven werk juist bestaat uit de moeilijkste onderdelen — of rondt het team een leverbare deelverzameling af en beschouwt het de sprint als voltooid, terwijl de rest half af blijft. Beide scenario’s zijn slechter dan het werk bewust opsplitsen voordat de sprint begint.

One oversized story splitting into three thinner slices ? ? too big won't fit in a sprint ✓ slice 1 shippable ✓ slice 2 shippable ✓ slice 3 shippable each slice ships on its own
Het verhaal dat niet in één geheel past, wordt opgesplitst in drie delen die elk afzonderlijk worden verzonden — en niet in twee helften van niets.

Waarom een groot verschil in stemmen een verdeeldheid betekent, en geen nieuwe stemming

Wanneer een team met planning poker werkt, is een grote spreiding het meest bruikbare signaal dat hieruit voortkomt. Kaarten die variëren van 3 tot 13 duiden niet op een meningsverschil over de cijfers. Het zijn twee verhalen die zich voordoen als één. Degene die een 3 stemt, ziet de ene omvang; degene die een 13 stemt, ziet een andere omvang. Opnieuw stemmen zal deze verschillen niet wegwerken — het gaat om het gesprek over welke omvang de juiste is. Dit is wat er doorgaans achter de schermen gebeurt:

  • De ene persoon houdt rekening met het ideale scenario; de andere houdt rekening met de uitzonderingsgevallen.
  • De ene persoon gaat ervan uit dat het ontwerp al bestaat; de andere gaat ervan uit dat hij of zij het aan het ontwerpen is.
  • De ene persoon houdt zich bezig met de omvang van de zoekopdracht; de andere met de omvang van de uitrol.
  • De ene persoon weet dat de afhankelijkheid bestaat; de andere niet.
  • Eén persoon is bezig met het bepalen van de afmetingen voor iemand in de ruimte; het werk valt onder de verantwoordelijkheid van een ander team.

Meer details lossen dit zelden op — het leidt tot een langer ticket, niet tot een nauwkeurigere schatting. Opsplitsen wel: in een piek als de onbekende factor de oorzaak is, in verticale segmenten als de onbekende factor de omvang betreft. Dat er twee kaarten worden neergelegd, betekent niet dat het team het oneens is. Het betekent dat het team stemt over verschillende verhalen. Stuur het terug.

Snijd verticaal, niet horizontaal

De opsplitsing moet verticaal zijn — een dunne plak die op zichzelf daadwerkelijk kan worden opgeleverd — en niet horizontaal. „Eerst de backend, de frontend in de volgende sprint” splitst het verhaal op dezelfde manier als een mes deeg doorsnijdt: u krijgt twee helften van niets. Een verticale segmentatie raakt elke laag en levert een werkende kolom op — één knop die van begin tot eind functioneert, zelfs als deze slechts één invoergeval verwerkt. Zie horizontale versus verticale segmentatie voor het volledige principe.

Effectieve opdelingspatronen

SPIDR — spike, path, interface, data, rules — dekt de meeste splitsingssituaties af en is de eerste plaats waar u moet kijken. Er zijn nog enkele andere patronen die vaak genoeg voorkomen om het vermelden waard te zijn.

Stappen in de workflow

Een user story die een gebruikersreis omvat — aanmelden, voorkeuren instellen, e-mail bevestigen, het dashboard bekijken — valt vaak netjes uiteen langs de grenzen van de afzonderlijke stappen. Als dit goed werkt, is het de meest overzichtelijke techniek uit het instrumentarium: elke user story levert een herkenbaar, voor de gebruiker zichtbaar resultaat op, elke user story kan worden gedemonstreerd en elke user story kan afzonderlijk worden afgebakend.

De test bestaat uit één vraag, die bij elke stap wordt gesteld: zou de gebruiker hier baat bij hebben als we alleen dit zouden uitbrengen en verder niets? „Voorkeuren instellen” voldoet aan de test — een gebruiker met voorkeuren maar zonder e-mailbevestiging bevindt zich nog steeds in een bruikbare toestand. “Formulier verzenden” voldoet niet — een gebruiker wiens verzending nergens toe leidt, is slechter af dan voorheen. Als het antwoord ‘nee’ is, is de stap een subtaken en geen story, en wordt de workflow daar niet opgesplitst.

De snellere versie van dezelfde test: zou elke stap binnen drie sprints in productie kunnen worden genomen zonder dat er verder iets verandert, en bij elke stap een samenhangende gebruikerservaring bieden? Als het overslaan van een stap ertoe leidt dat de gebruiker een defecte pagina te zien krijgt, is de opsplitsing onjuist. Dat is de valkuil waar engineeringteams in trappen — de stappen komen overeen met de manier waarop de code is opgedeeld (authenticatieservice, voorkeuren-API, dashboardcomponent), waardoor ze gedetailleerd aanvoelen. Ze zijn inderdaad gedetailleerd. Het zijn echter ook horizontale segmenten met workflowterminologie eroverheen, en geen enkele daarvan levert daadwerkelijk iets op voor de gebruiker. De aanwijzing: elke „stap“ valt onder de verantwoordelijkheid van precies één specialist. Echte workflowstappen overschrijden de stack, omdat echte, voor de gebruiker zichtbare stappen dat ook doen.

Variaties in bedrijfsregels

Een verhaal met meerdere regels of rollen — gewone gebruiker, beheerder, API-client — wordt per regel opgesplitst. Implementeer eerst de meest gangbare regel; de varianten volgen daarna. Elke variant is een volwaardig verhaal met zijn eigen gebruikers.

Het gunstige scenario, gevolgd door het ongunstige scenario

Dit hangt nauw samen met de Path-aanpak van SPIDR. Lever eerst het ‘happy path’ op; foutafhandeling, herpogingen en randgevallen volgen daarna. De gebruiker kan al succes boeken nog voordat de foutmodi volledig zijn afgehandeld — mits u in de tussentijd genoegen neemt met minder goed foutgedrag, en u er later daadwerkelijk op terugkomt.

Uitgestelde kwaliteit

Breng de release uit zonder de afwerking — geen tooltips, geen animaties, geen beheerdersaanpassingen — en breng de afwerking vervolgens uit als een apart verhaal. Dit werkt als u de afwerking daadwerkelijk uitbrengt. Teams die kwaliteit opzij schuiven en er nooit op terugkomen, blijven uiteindelijk zitten met halfafgewerkte functies.

Bedrijfsvoering

Een verhaal dat deels betrekking heeft op een gebruikersfunctie en deels op operationele aspecten (logboekregistratie, monitoring, waarschuwingen) wordt langs die lijn opgesplitst. Breng het gebruikersgerichte deel eerst in productie; het operationele deel volgt daarna en verloopt vaak sneller, omdat de functie dan al in productie is en de tekortkomingen zichtbaar zijn.

Wat is geen echte splitsing?

“Deze sprint de frontend, de volgende sprint de backend” is geen opsplitsing — het is het uitstellen van de oplevering, omdat geen van beide helften afzonderlijk iets oplevert. “Eerst bouwen, dan de tests schrijven” is hetzelfde principe: ongeteste code is een risico, geen afzonderlijk onderdeel. Als een onderdeel pas waarde heeft zodra het bijbehorende onderdeel is opgeleverd, hebt u het verhaal niet opgesplitst. U hebt het ingepland.

Wanneer een verhaal niet kan worden opgesplitst: voer een spike uit

Soms is de onbekende factor de omvang zelf — niemand heeft dit eerder gedaan, de API van de leverancier geeft geen antwoord op de vraag naar de belastbaarheid, of het werk is afhankelijk van een meting waarover nog niemand beschikt (huidige p99, huidig gespreksvolume, huidige gegevensstructuur). Dat is het moment waarop u een spike uitvoert: een onderzoek met een vaste tijdslimiet waarvan de output kennis is — een document, een prototype, een aanbeveling, een meting — en geen productcode die daadwerkelijk wordt uitgebracht. U keert terug met de mogelijkheid om de werkelijke situatie eerlijk in te schatten.

Spikes worden vaak verkeerd gebruikt in de zin van „laten we gewoon beginnen en kijken wat er gebeurt”. Dat is geen spike — het is een niet-ingeschatte story met extra stappen. Twee signalen dat u het verkeerde hulpmiddel gebruikt: er wordt geen specifieke vraag beantwoord, of het eindresultaat is „de functie is gebouwd“. Het eerste betekent dat het team eigenlijk niet onzeker is; het tweede betekent dat het een story is.

Als één enkel onderdeel er nog steeds niet in past, is het verhaal nog niet klaar — het is een project. Benader het als zodanig, geef duidelijkheid over de tijdlijn en doe niet alsof het binnen één sprint afgerond kan worden.

Veelgestelde vragen

Hoe splitst u een user story op?

Verdeel het verticaal — op basis van gebruikersresultaten, zodat elk deel elke laag raakt en iets oplevert dat een gebruiker kan gebruiken, zelfs als het slechts één specifiek geval afhandelt. SPIDR biedt vijf betrouwbare scheidingslijnen: spike, pad, interface, gegevens, regels. Kies degene die een deel oplevert dat u daadwerkelijk zou vrijgeven.

Wat doet u als een user story te omvangrijk is voor een sprint?

Deel het bewust op voordat de sprint begint. Een story die niet past, wordt op een ongewenste manier doorgeschoven — het overblijvende deel is dan precies datgene wat het moeilijkst was — of als een half afgebouwde subset opgeleverd. Beide opties zijn slechter dan een bewuste verticale opsplitsing in delen die elk afzonderlijk worden opgeleverd.

Wanneer dient u een verhaal op te splitsen in plaats van het in te schatten?

Wanneer het team het niet in een sprint kan inpassen, wanneer de stemmen sterk uiteenlopen (een 3 naast een 13), wanneer op meer dan een paar verduidelijkingsvragen met „dat hangt ervan af” wordt geantwoord, of wanneer het verhaal zich over meer dan één team uitstrekt. Een grote spreiding duidt niet op een meningsverschil over cijfers — het zijn twee verhalen die doen alsof ze één zijn.

Wat is een „spike“ binnen agile?

Een spike is een onderzoek met een vastgestelde tijdsduur, dat wordt uitgevoerd wanneer het team de omvang van een story niet kan inschatten zonder eerst meer informatie te verzamelen. Het resultaat is kennis — een document, een prototype, een meting — en geen productcode die wordt uitgebracht. Twee zaken maken het tot een spike in plaats van werk met een open einde: een tijdslimiet en een te leveren resultaat.

Wat zijn de gebruikelijke manieren om een user story op te splitsen?

Workflowstappen, variaties in bedrijfsregels, het ‘happy path’ en vervolgens het ‘unhappy path’, uitgestelde kwaliteitscontrole en operationele aandachtspunten — plus de vijf SPIDR-segmenten. De toets voor al deze aspecten is dezelfde: zou de gebruiker er baat bij hebben als alleen dit segment zou worden opgeleverd en verder niets?

Aanbevolen lectuur