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 gepubliceerd kan worden. 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 te omvangrijk verhaal opsplitst in kleinere verhalen die elk nog steeds iets opleveren waar een gebruiker iets aan heeft. Een verhaal dat u niet kunt inschatten, is doorgaans een verhaal dat u nog niet kunt opleveren, en door het op te splitsen kunt u het weer op het bord plaatsen.

De meeste gesprekken waarin wordt gezegd „dit kunnen we niet inschatten” zijn in feite gesprekken over het opsplitsen van taken. Het team kampt niet met een probleem op het gebied van cijfers en werkinspanning; het probleem is dat er te veel onbekende factoren zijn. Door de taak 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.
  • “Klaar” vereist meerdere implementaties.
  • U kunt het in twee zinnen beschrijven, maar niet in twee aanvaardingscriteria.

Als u er toch mee doorgaat, besteedt het team de sprint aan pogingen om het af te krijgen en wordt het resterende werk doorgeschoven (wat ongewenst is, omdat het doorgeschoven werk juist het moeilijkste deel is), of maakt het een leverbare subset 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 het niets.

Waarom een groot verschil in stemmen duidt op verdeeldheid en niet op een nieuwe stemming

Wanneer teamleden met planning poker samenwerken, is een grote spreiding het meest bruikbare signaal dat hieruit voortkomt. Kaarten die variëren van 3 tot 13 duiden niet op onenigheid 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 geen overeenstemming brengen; 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 randgevallen.
  • 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 het bepalen van de omvang van de zoekopdracht; de andere met het bepalen van de omvang van de implementatie.
  • 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 werkt wel: in een piek als de onbekende factor de oorzaak is, in verticale segmenten als de onbekende factor de omvang betreft. Twee verspreide kaarten betekenen niet dat het team het oneens is. Het betekent dat het team stemt over verschillende verhalen. Stuur het terug.

Snijd verticaal, niet horizontaal

De opdeling moet verticaal zijn, niet horizontaal: een dunne plak die op zichzelf daadwerkelijk kan worden opgeleverd. „Eerst de backend, de frontend in de volgende sprint” verdeelt het verhaal zoals een mes deeg snijdt: u krijgt twee helften die niets opleveren. 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, dashboard bekijken) valt vaak netjes uiteen langs de grenzen van de afzonderlijke stappen. Wanneer 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 wij 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 er slechter aan toe dan voorheen. Indien het antwoord „nee“ is, is de stap een subtaken en geen story, en wordt de workflow op dat punt 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 ongeldig. 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 daarop workflowterminologie, en geen enkele daarvan levert daadwerkelijk iets op voor de gebruiker. Het kenmerk: 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. Breng eerst de meest gangbare regel in gebruik; 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, herhalingspogingen en randgevallen volgen daarna. De gebruiker kan al succes boeken nog voordat de foutmodi volledig zijn afgehandeld, mits u in de tussentijd slechter foutgedrag accepteert en u hier 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 afzonderlijke release. 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 een gebruikersfunctie en deels een operationele aangelegenheid betreft (logboekregistratie, monitoring, waarschuwingen) valt langs die lijn uiteen. 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 delen afzonderlijk wordt opgeleverd. “Eerst bouwen, dan de tests schrijven” volgt hetzelfde patroon: 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 dan 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 uitgerold. Na afloop bent u in staat om de werkelijke omvang van het project 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 de verkeerde methode gebruikt: er wordt geen specifieke vraag beantwoord, of het te leveren resultaat is „de functie is gebouwd“. Het eerste betekent dat het team eigenlijk niet onzeker is; het tweede betekent dat het een verhaal is.

Als één enkel onderdeel nog steeds niet past, is het verhaal nog niet klaar; het is een project. Beschouw het als één geheel, geef duidelijkheid over de tijdlijn en doe niet alsof het binnen één sprint kan worden afgehandeld.

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: piek, pad, interface, gegevens, regels. Kies degene die een deel oplevert dat u daadwerkelijk zou vrijgeven.

Wat doet u wanneer 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 onbevredigende manier doorgeschoven (waarbij het overblijvende deel het moeilijkste onderdeel is) of als een half afgewerkte deelset 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 is geen 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 meer informatie te verkrijgen. Het resultaat is kennis (een document, een prototype, een meting), en geen productcode die wordt uitgebracht. Twee zaken zorgen ervoor dat het een spike is 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