Met ‘story points’ flexibiliteit in fixed-fee projecten
Veel opdrachtgevers hebben behoefte aan zekerheid en kiezen bij de ontwikkeling van een maatwerk webapplicatie voor een aanpak op basis van een vaste prijs. Dat kan echter problemen opleveren als de wensen door voortschrijdend inzicht veranderen. Met behulp van user stories en story points is het, ook bij fixed-fee projecten, mogelijk om flexibel om te gaan met wijzigingen.
Bij het laten ontwikkelen van een website of webapplicatie moeten opdrachtgever en opdrachtnemer het op voorhand over een aantal zaken eens worden. De belangrijkste aspecten zijn de ‘scope’ van de oplossing, de planning van het project, de gewenste kwaliteit en de prijs. Deze vier elementen worden samen ook wel het duivelsvierkant genoemd, omdat het in de praktijk niet mogelijk is om elk element te maximaliseren. Zo levert een voordeel in de prijs (een besparing) onvermijdelijk een beweging ten nadele van de kwaliteit (lagere kwaliteit), de scope (minder functionaliteit), de planning (het project zal langer duren) of een combinatie van deze drie op.
Met bovenstaande in het achterhoofd, wil ik voor de context van dit artikel vier stellingen over maatwerk webprojecten introduceren:
- Stelling 1: Opdrachtgevers hebben behoefte aan zekerheid en in veel gevallen wenst men daarom op voorhand de investering (prijs) duidelijk te hebben.
- Stelling 2: Opdrachtgevers willen doorgaans dat de oplossing zo snel mogelijk geïmplementeerd wordt. Dat betekent dat de meeste projecten een “ambitieuze planning” kennen en er geen of nauwelijks ruimte voor vertraging is.
- Stelling 3: Opdrachtgever en opdrachtnemer kunnen tijdens de offertefase nooit de volledige reikwijdte van de wensen overzien. Hoe vaak en zorgvuldig er van tevoren ook met elkaar wordt gesproken, er ontstaan tijdens projecten altijd nieuwe inzichten en er zijn dan ook altijd veranderingen in de requirements.
- Stelling 4: In de praktijk wenst vrijwel elke opdrachtgever een kwalitatief hoogstaande oplossing te realiseren.
Als de prijs, de planning en de gewenste kwaliteit vaststaan, dan zal een opdrachtnemer over het algemeen niet blij zijn met wijzigingen in de gewenste functionaliteit (scope). Een verandering levert immers extra werk op, terwijl er geen groter budget of een ruimere planning tegenover staat. Dat betekent dat zelfs kleine wijzigingen bij “fixed scope/fee/schedule/quality”-projecten tot problemen tussen opdrachtgever en opdrachtnemer kunnen leiden.
Flexibiliteit in de scope
Aangezien veel opdrachtgevers het budget en de planning willen vastzetten en geen concessies aan de kwaliteit wensen te doen, wordt binnen Scrum aangeraden om de scope van een project flexibel te houden. In de praktijk zien wij daar drie varianten in:
- De scope is volledig flexibel. Het project wordt vanuit een sterke visie gestart, maar de gewenste oplossing staat niet op voorhand vast. Tijdens het project wordt de oplossing stapsgewijs gedefinieerd en geïmplementeerd. Deze aanpak is handig voor projecten waarbij de oplossingsrichting op voorhand nog erg vaag is. De opdrachtgever zal gegarandeerd een oplossing krijgen die bij zijn behoefte (of die van de markt) past, maar wat de oplossing precies is, is op voorhand onduidelijk.
- De scope is vast, maar in de projectbegroting is een “buffer” voor meerwerk opgenomen. Bij deze variant is de scope op voorhand zo ver als mogelijk uitgedacht, maar erkennen opdrachtgever en opdrachtnemer dat de wensen door voortschrijdend inzicht waarschijnlijk nog iets worden uitgebreid. In de begroting wordt daar vast rekening mee gehouden door een percentage meerwerk te voorzien.
- De scope is op voorhand uitgedacht, maar er is een budgetneutraal mechanisme voor veranderingen. Deze aanpak is wenselijk bij overzichtelijke projecten waarin de gewenste oplossingsrichting vrij gedetailleerd is uitgewerkt (bijvoorbeeld tijdens een concepttraject), maar opdrachtgever en opdrachtnemer erkennen dat de éxacte oplossingsrichting pas tijdens het project helemaal duidelijk wordt.
In de manier waarop wij werken, staan drie zaken centraal: gelukkige klanten, geweldige producten en enthousiaste eindgebruikers.
De eerste variant past helemaal bij Scrum. Bij een “Scrumproject volgens het boekje” zal in principe nooit met een vaste scope gewerkt worden. Maar voor opdrachtgevers die nog geen ervaringen met dit type softwareontwikkeling hebben, is het soms een brug te ver. Daarnaast zijn opdrachtgevers in mijn ervaring vaak niet happig op variant 2 omdat de begroting van het project effectief toeneemt (en dus de financiering lastiger wordt), ook al hoeft het niet zo te zijn dat de buffer ook echt gebruikt wordt.
Als opdrachtgevers variant 1 niet aandurven, dan adviseren wij om variant 3 toe te passen. Ons mechanisme om budgetneutraal flexibiliteit in een “fixed fee/schedule/quality”-project te krijgen en zo ruimte voor voortschrijdend inzicht te creëren is gebaseerd op user stories en story points.
"User stories en story points helpen om flexibiliteit te brengen in een fixed fee project."
Story points als mechanisme voor flexibiliteit
Met user stories schrijven de opdrachtgever en de opdrachtnemer de gewenste functionaliteit uit in kleine verhaaltjes. Een voorbeeld: “Als Redacteur kan ik een blogartikel aanmaken, zodat ik mijn verhaal met anderen kan delen”. Daarna worden de user stories aangevuld met alle relevante details.
Vervolgens vindt aan de zijde van de opdrachtnemer de planning poker meeting plaats. Tijdens deze sessie schat elke developer voor zichzelf de complexiteit van de user stories in. Daarvoor worden story points (ook wel: ‘complexity points’) gebruikt (zelf gebruiken wij een reeks getallen uit de Fibonacci-reeks: 1, 2, 3, 5, 8, 13, et cetera). De schattingen worden onderling besproken en voor elke user story vastgesteld. Bovenstaande user story zou na de planning poker meeting bijvoorbeeld op 8 story points kunnen uitkomen. Het aantal punten zegt dus iets over de complexiteit van die specifieke story en daarmee ook over de implementatiekosten. Bovendien kunnen wensen met elkaar vergeleken worden: user story 0023 heeft een complexiteit die vergelijkbaar is met user story 0045 (bijvoorbeeld allebei 5 punten).
De opdrachtnemer zal de fixed fee offerte vervolgens berekenen op basis van het totaal aantal story points en de gemiddelde prijs per punt. De kern van het mechanisme is nu dat de opdrachtgever een (minder belangrijke) user story budgetneutraal kan inwisselen voor een nieuwe (belangrijkere) user story op basis van het aantal story points. Of meerdere user stories. Zolang de totale hoeveelheid werk gelijk blijft, heeft de gewijzigde functionaliteit geen of nauwelijks invloed op de planning, prijs of de gewenste kwaliteit. In dat kader spreken we van een “exchange request” in plaats van een “change request”.
Er zijn enkele voorwaarden om deze aanpak te laten slagen. Zo kan de opdrachtgever geen user stories inwisselen die al geïmplementeerd zijn, want anders zou de verandering alsnog effect op de planning en het budget hebben. Vandaar ook dat het belangrijk is om user stories zoveel mogelijk op volgorde van prioriteit (business value) te implementeren.
Daarnaast is het cruciaal dat er wederzijds veel vertrouwen tussen opdrachtgever en opdrachtnemer is. De opdrachtgever moet te allen tijde het gevoel hebben dat het developmentteam de complexiteit van de user stories naar eer en geweten inschat. Dat is een belangrijke reden om schattingen nooit door één persoon maar altijd door het complete ontwikkelteam te laten inschatten. Daarnaast moet de opdrachtnemer het gevoel hebben dat de opdrachtgever de inschattingen van het ontwikkelteam vertrouwt en respecteert.
Voorbeeld
Ter illustratie van het mechanisme een concreet voorbeeld:
Een opdrachtgever heeft contact opgenomen met een softwareontwikkelaar voor de realisatie van een online bestelsysteem. Na het doorlopen van een conceptfase hebben beide partijen een goed beeld van de gewenste functionaliteit. Er wordt een vaste fee voor de realisatie afgesproken en een planning die in totaal tien weken beslaat (vijf sprints van twee weken).
Na afronding van sprint 3 wordt duidelijk dat er een extra betaalmogelijkheid aan het bestelsysteem moet worden toegevoegd, omdat een concurrent die optie ook biedt. Het team schat de implementatie (in totaal drie user stories) op een totaal van 21 punten. In dit project is geen buffer voor meerwerk opgenomen.
Na overleg blijkt dat de functie om transacties te exporteren in PDF-formaat (drie user stories van in totaal 26 punten), die gepland stond voor sprint 5, eigenlijk maar beperkte waarde voor de opdrachtgever heeft. De opdrachtgever besluit nu om deze drie user stories buiten de scope van de eerste versie te plaatsen en daarvoor de nieuwe betaalmogelijkheid te introduceren. De resterende 5 punten worden gebruikt om kleine uitbreidingen op een andere functie te realiseren.
Conclusie
Door functionaliteit aan de hand van user stories en met behulp van story points inwisselbaar te maken, is het mogelijk om in een fixed fee project flexibiliteit te brengen. Onderling vertrouwen tussen opdrachtgever en opdrachtnemer is daarbij cruciaal.
Een introductie tot het ontwikkelen van succesvolle sites en apps.
Een korte uitleg over de rol van de product owner in een Scrumteam.