Marco Balvers en Dennis Geluk

Bij Agile/SCRUM projecten werken we vaak op basis van user stories. Elke user story beschrijft hierbij enerzijds een gebruikersdoel en anderzijds een werkpakket voor het ontwikkelteam. Bij elke sprint realiseert het ontwikkelteam één of meerdere user stories.

Bij langere projecten ontstaan op deze manier al snel grote hoeveelheden user stories. Daardoor is het vaak moeilijk om het overzicht te bewaren en de werking van het ontwikkelde systeem aan nieuwe projectleden of de beheerorganisatie uit te leggen.

Knippen vanuit het totaalbeeld

Hoe meer stories er al zijn gemaakt, hoe uitdagender het wordt om het totaalbeeld vanuit de stories te schetsen. User stories aan elkaar plakken is meestal arbeidsintensief en tijdrovend. Maar met de juiste aanpak is achteraf plakken niet nodig.

Bij DiVetro werken we bij grotere projecten al bij aanvang op basis van het totaalbeeld van het systeem. Dit totaalbeeld, de ‘big picture’, is van groot belang om tijdens het ontwerpen en ontwikkelen de juiste beslissingen te nemen. Het totaalbeeld knippen we op tot werkpakketten. Knippen is immers makkelijker dan plakken.

Vanuit het totaalbeeld kunnen we op elk moment de werking van het systeem en het belang van de individuele user stories uitleggen. Daarbij maken we bij DiVetro gebruik van de DiVetro standaards, handige hulpmiddelen die gebaseerd zijn op de Use Case 2.0 methodologie van Ivar Jacobson InternationaI.

We inventariseren eerst de needs en features van het systeem dat we moeten ontwikkelen. Vervolgens stellen we een use case model op. Dit doen we tijdens een workshop met de diverse stakeholders binnen het project.

Het use case model biedt een overzicht van alle functionaliteiten van het systeem. Elke functionaliteit is hierbij geformuleerd als een gebruikersdoel in de vorm van een use case.

Een use case is daarbij uitdrukkelijk geen werkpakket voor het ontwikkelteam. De omvang van de functionaliteit binnen een use case is immers vaak anders dan de omvang van de functionaliteit die wordt beschreven met behulp van een user story. (Lees voor meer informatie ook ‘3 overeenkomsten en 3 verschillen tussen use cases en user stories’)

We voorzien elke use case van een korte omschrijving en de actor die de use case uitvoert. Daarmee hebben we een eerste overzicht van de gewenste functionaliteiten van ons project.

Agile werken vanuit het totaalbeeld

Vervolgens kiezen we de use case waar we mee van start willen gaan. Deze werken we uit tot het minimale detailniveau dat precies voldoende is om werkpakketten op hoofdlijnen te definiëren.

Dan knippen we de functionaliteit van de use case op en creëren we use case slices. Een use case slice is qua omvang vergelijkbaar met een user story, maar de use case slice is in de context van de use case te plaatsen. Daarmee heeft de use case slice een plekje in het totaalbeeld.

We houden ons tijdens het project altijd aan de volgende agile principes:

• Werk alleen de use case(s) uit waar je daadwerkelijk mee aan de slag gaat
• Beschrijf alleen de outline van de use case (het minimale detailniveau)
• Definieer de use case slices van de use case
• Detailleer alleen de use case slices die het hoogst op de backlog staan
• Detailleer de use case slices tot een niveau dat nodig is voor het team om refinement te kunnen doen

Bijwerken van de documentatie

Nadat we een use case slice beschreven hebben kan het team deze use case slice inschatten en realiseren. Hierbij is het zeer belangrijk dat de documentatie aan het einde van de sprint weer up-to-date is. Zo weten we precies wat het systeem op dat moment kan. Deze informatie kan vervolgens weer als context voor de volgende use case slices dienen.

We kunnen kiezen om de use case bij de start van de sprint uit te werken en die als basis voor het ontwikkelwerk te nemen, maar we kunnen ook de use case slice als basis voor het ontwikkelwerk gebruiken. In dat geval werken we de use case bij als onderdeel van de ‘Definition of Done’ van de sprint.

Voordelen van deze werkwijze

Bij kleinschalige projecten kunnen user stories volstaan. Maar bij grootschalige en langere projecten, waarbij de applicaties een langere levenscyclus hebben, werken we bij DiVetro vaak op basis van use cases, niet op basis van alleen maar individuele user stories. Deze werkwijze biedt ons diverse voordelen:

• We hebben altijd overzicht over de gewenste functionaliteiten van het systeem
• Dit overzicht is een handig startpunt voor nieuwe projectmedewerkers en nieuwe bedrijfsonderdelen die aansluiten bij het project
• We hebben op elk moment actuele documentatie van wat het systeem op dat moment ondersteunt
• Deze documentatie dient als context voor de volgende sprint, waardoor we betere beslissingen kunnen nemen over kosten, scope en consistentie.

Hoe gaat u te werk?

Vaak worden Agile/SCRUM projecten alleen gedocumenteerd op basis van individuele user stories. Bij grootschalige en langere projecten wordt na verloop van tijd het aantal stories vaak te groot en moeten de stories aan elkaar worden geplakt om een totaalbeeld te vormen. Dat is echter tijdrovend en kostbaar.

Daarom kiezen wij bij DiVetro bij grootschalige en langere projecten voor een andere aanpak.

Wij starten vanuit het totaalbeeld van het project. Op basis daarvan maken we slices of stories . Deze aanpak biedt interessante voordelen: we houden het overzicht en we bouwen alle noodzakelijke documentatie tijdens de sprints op.

Welke aanpak verkiest u?

Vragen of opmerkingen?

Heeft u vragen of opmerkingen over agile werken of de impact van agile werken op uw requirements? Aarzel niet en deel uw vragen en opmerkingen via het reactieformulier onderaan deze pagina, via info@divetro.nl of via +31 (0) 88 000 54 00. Wij helpen u graag verder.

Blijf op de hoogte

Wilt u meer van dit soort blog posts lezen? Meld u dan aan voor onze nieuwsbrief. U ontvangt onze blog posts dan automatisch in uw mailbox.

Meld u aan voor onze nieuwsbrief