Horizontaal versus verticaal snijden

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

Horizontaal snijden is net zoals een mes deeg doorsnijdt — u krijgt twee helften van niets.

Het verschil

Bij horizontale opdeling wordt het werk verdeeld over de architecturale lagen: deze sprint de frontend, de volgende sprint de backend en de sprint daarna de database. Het werk past weliswaar 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 verwerkt. Het team levert minder op per segment, maar elk segment is een echt, 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 uitbrengen van een nep-backend is reëel — maar het is kleiner dan het ongemak van het drie sprints lang niets uitbrengen.

De uitzondering: fundamenteel platformwerk

Sommige infrastructuuronderdelen hebben pas na voltooiing een voor de gebruiker zichtbaar onderdeel — zoals 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 weerspiegeling zal zijn van de investering. Het opdienen van een migratie van drie sprints als drie „stories“ houdt alleen de burndown-grafiek voor de gek.

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

Veelgestelde vragen

Wat houdt ‘vertical slicing’ in bij agile?

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

Wat is het verschil tussen horizontaal en verticaal segmenteren?

Bij horizontale opdeling wordt er per technische laag gewerkt — de frontend in de ene sprint, de backend in de volgende — waardoor 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 elk onderdeel een concreet, leverbaar resultaat 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 opdeling verhoogt de snelheidscijfers, terwijl het product dat de gebruiker te zien krijgt gedurende meerdere sprints tegelijk ongewijzigd blijft.

Wanneer is horizontale opsplitsing aanvaardbaar?

Wanneer het gaat om fundamenteel platformwerk waarbij er nog geen voor de gebruiker zichtbaar onderdeel is voltooid — het migreren van authenticatieproviders, het vervangen van een wachtrij-backend, het vernieuwen van de implementatiepijplijn. Dat zijn projecten, geen user 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-inschatting: de complete gids — hier vindt u alle informatie hierover.