Horizontaal versus verticaal snijden

Bij verticale segmentering wordt een verhaal opgesplitst op basis van gebruikersresultaten; bij horizontale segmentering gebeurt dit op basis van technische lagen. Die ene keuze bepaalt of elke segmentatie iets oplevert of niets. Verticale segmentaties leveren waarde op. Horizontale segmentaties leveren beloften op.

Horizontaal snijden is hetzelfde als de manier waarop een mes deeg doorsnijdt: u krijgt twee helften van niets.

Het verschil

Bij horizontale opdeling wordt het werk verdeeld over architecturale lagen: frontend in deze sprint, backend in de volgende, en de database in de sprint daarna. Het werk past binnen de sprints, maar geen enkele sprint levert iets op dat gebruikers daadwerkelijk kunnen ervaren. De velocity-cijfers van het team stijgen; het changelog voor gebruikers blijft echter leeg.

Verticale opdeling vindt plaats op basis van gebruikersresultaten. Een dunne segmentatie die elke laag raakt: één enkele knop die daadwerkelijk van begin tot eind functioneert, zelfs als deze slechts één invoergeval afhandelt. Het team levert per segment minder op, maar elk segment is een concreet, leverbaar geheel. Het changelog vult zich, gebruikers zien vooruitgang en het team kan de koers bijstellen op basis van daadwerkelijk gebruik in plaats van voorspeld gebruik.

Wanneer horizontale segmentering noodzakelijk lijkt

Dat is meestal niet het geval. „We hebben het databaseschema nodig voordat we de gebruikersinterface kunnen bouwen” is de klassieke rechtvaardiging, en die maakt bijna altijd plaats voor „we kunnen het antwoord hardcoderen, de gebruikersinterface opleveren en de database in de volgende fase bouwen.” Het ongemak van het opleveren van een nep-backend is reëel, maar het is kleiner dan het ongemak van het drie sprints lang niets opleveren.

De uitzondering: fundamenteel platformwerk

Sommige infrastructuuronderdelen hebben geen voor de gebruiker zichtbaar onderdeel totdat ze volledig zijn voltooid: de migratie naar een nieuwe authenticatieprovider, het vervangen van een wachtrij-backend of het vernieuwen van de implementatiepijplijn. Dit zijn projecten, geen user stories. Behandel ze dan ook als zodanig: splits ze niet horizontaal op en doe niet alsof. Bepaal de omvang ervan als een project, communiceer de tijdlijn en accepteer dat de snelheid van het team een afspiegeling zal zijn van de investering. Het voorstellen van een migratie van drie sprints als drie „verhalen“ misleidt alleen de burndown-grafiek.

Als een slice niets bevat dat een gebruiker kan gebruiken, is het geen slice.

Veelgestelde vragen

Wat houdt ‘verticaal opdelen’ in bij agile?

Bij verticaal opdelen wordt een verhaal opgesplitst op basis van gebruikersresultaten, zodat elk deel een dunne doorsnede vormt door alle lagen heen (gebruikersinterface, logica en gegevens) en iets oplevert dat een gebruiker daadwerkelijk kan gebruiken, zelfs als het slechts één specifiek geval afhandelt. Elk deel kan afzonderlijk worden uitgebracht.

Wat is het verschil tussen horizontaal en verticaal segmenteren?

Bij horizontale opdeling wordt er per technische laag gewerkt: de ene sprint is voor de frontend en de volgende voor de backend, zodat er in geen enkele sprint iets wordt opgeleverd dat de gebruiker daadwerkelijk kan gebruiken. Bij verticale opdeling wordt er per gebruikersresultaat gewerkt, zodat elke opdeling een werkend end-to-end-traject oplevert. Verticale opdelingen leveren waarde op; horizontale opdelingen leveren beloften op.

Waarom is verticale opdeling beter?

Omdat elke ‘slice’ een concreet, leverbaar onderdeel is. De changelog vult zich, gebruikers zien vooruitgang en het team kan de koers bijstellen op basis van daadwerkelijk gebruik in plaats van voorspeld gebruik. Horizontale segmentering verhoogt de velocity-cijfers, terwijl het voor de gebruiker zichtbare product gedurende meerdere sprints ongewijzigd blijft.

Wanneer is horizontale opdeling aanvaardbaar?

Wanneer het gaat om fundamenteel platformwerk zonder dat er een voor de gebruiker zichtbaar onderdeel is dat nog niet voltooid is: het migreren van authenticatieproviders, het vervangen van een wachtrij-backend, het vernieuwen van de implementatiepijplijn. Dit zijn projecten, geen stories: beoordeel de omvang ervan als zodanig en communiceer de tijdlijn, in plaats van te doen alsof ze in kleinere delen kunnen worden opgesplitst.

Aanbevolen lectuur

• Het opsplitsen van user stories: de volledige toolkit, en hoe u een echte opsplitsing van een nep-opsplitsing kunt onderscheiden.
• SPIDR-verhaalsplitsing: vijf betrouwbare verticale segmenten.
• Agile-schatting: de complete gids: hier vindt u alle informatie hierover.