Scrum Blog #3: Refinement

Als Scrum het spel der liefde zou zijn, dan is refinement het voorspel: als je daar genoeg tijd aan besteedt, dan wordt de rest één groot feest.

Om precies dat te maken wat de opdrachtgever wil, hebben softwareontwikkelaars en -testers duidelijke, beknopte en volledige specificaties nodig. Juist hierbij geldt het GIGO-principe: garbage in, garbage out. Als de specificaties ruimte voor interpretatie openlaten, dan laat men het aan de ontwikkelaar over wat deze daar mee doet. Als de designs tot op tien cijfers achter de komma uitgekauwd worden, dan heeft de ontwikkelaar helemaal geen eigen inbreng, wat demotivatie en een matig presterend team tot gevolg kan hebben. Daarbij kost het maken van deze specs dan veel meer tijd. Hoe beschrijf je nu het beste hoe die liefdesbaby eruit moet komen te zien?

Waarom speciferen we?

We specificeren om de eisen in documentvorm over te kunnen dragen aan de belanghebbenden. Het is een soort van contract. Niet alleen voor ontwikkelaars, maar ook voor testers en de opdrachtgever. Daarnaast is het vaak zo (maar niet altijd!) dat het uit te voeren werk ingeschat moet worden. Ook daar hebben de specificaties een rol. Dan volgt de vraag:

Wat speciferen we?

Vrij gebruikelijk: we leggen alles vast dat beschrijft of verduidelijkt wat er opgeleverd moet worden en hoe dat met de omgeving moet interacteren.

Afhankelijk van het soort oplossing dat gemaakt moet worden zullen er verschillende soorten specificaties gemaakt worden. Een website gericht op een groot publiek zal een mooi grafisch ontwerp nodig hebben en er zal over gebruikerservaringen (User Experience – UX) nagedacht moeten worden. Een zogenaamd back-end systeem kan verbinden met andere back-end systemen, waarvan duidelijk moet zijn welk soort berichten gecommuniceerd worden volgens welk protocol.

Tip: beschrijf altijd voor wie, wat en waarom er iets gemaakt moet worden in de vorm van een user story. Dat klinkt eenvoudig en logisch, maar wordt lang niet altijd daadwerkelijk zo uitgevoerd. En elke user story heeft altijd één, maar vaak meerdere scenario’s. Leg ook deze vast, want deze geven een goed beeld van wat er gemaakt moet worden en hoe complex de user story is.

Verder kun je het doel nog verder verduidelijken met (bijvoorbeeld) schetsen of draadmodellen van schermen, een grafisch ontwerp, interactiebeschrijvingen op en met andere schermen (screen flows) en interactie met andere systemen. Om aannames te voorkomen kun je ook uitsluitingen benoemen, dus dat wat expliciet niet gemaakt moet worden.

Voor het beter kunnen maken van inschattingen kun je een opsomming maken van de schermen en technische componenten die gemaakt moeten worden. Maar let op: beschrijf niet te veel technische details, tenzij het om complexe formules o.i.d. gaat. Geef ontwikkelaars de ruimte om enige creativiteit en/of inventiviteit te tonen. De ontwikkelaars kunnen onderling prima afstemmen hoe lijsten samengesteld worden, hoe aantallen geteld moeten worden en hoe het zoveelste dertien-in-een-dozijn-componentje moet heten.

Tip: laat het Scrum team een checklist maken van wat beschreven moet worden. Deze checklist wordt ook wel de Definition of Ready (niet te verwarren met de Definition of Done) genoemd. Het ontwikkelteam kan goed beslissen wat zij aan specificaties nodig hebben.

Hoe specificeren we?

Alsjeblieft, alsjeblieft: maak het duidelijk en beknopt! Natuurlijk: al het nodige moet erin staan, maar alles wat er extra in staat, is meestal ruis. Een user story is een conventie en als je een user story niet als user story beschrijft, dan is het er dus geen. De wereldwijd gangbare notatiewijze is: Als [rol] wil ik [functionaliteit], zodat ik [motivatie].

Bijvoorbeeld: Als anonieme bezoeker van de website wil ik kunnen zoeken in productcatagolus, zodat ik snel het product kan vinden dat ik zoek

Hiermee wordt in één zin het hoe en waarom van de user story beschreven. Voor de opdrachtgever lijkt het motivatie-deel vaak logisch, maar voor de ontwikkelaar en tester hoeft dat helemaal niet zo vanzelfsprekend te zijn. Voor hen is dit zeer waardevolle informatie, omdat ze hiermee inzicht krijgen in de gebruiker en diens behoefte.

Voor het opstellen van de user story moet goed overwogen worden wie nu echt iets wil. Een eindgebruiker wil geen modulair opgebouwde website of een kolom met advertenties: dat willen de architect en de eigenaar van de website. Als ergens geen rol aan te koppelen is, dan is er ook geen reden om de user story te maken en kan het, wat mij betreft rücksichtslos weggelaten worden.

Elke user story heeft tenminste één en vaak meerdere scenario’s. Schrijf deze bij voorkeur in een onderling afgestemde, SMART beschreven notatiewijze. Dat klinkt logisch, maar is voor velen een uitdaging. Wees alert wanneer woorden als ‘snel’, ‘veel’ of ‘gebruiksvriendelijk’ worden gebruikt: deze kunnen een allergische reactie bij ontwikkelaars oproepen.

Een voorbeeld van een vrij eenvoudige notatiewijze: Gegeven [uitgangspunt]. Als [actie], dan [verwacht resultaat].

Bijvoorbeeld: Gegeven het zoekvenster. Als de bezoeker een zoekterm invult en op de zoekknop klikt, dan worden de zoekresultaten in een lijst getoond, waarbij de lijst de kolommen Productnaam en Prijs bevat en aflopend gesorteerd is op Prijs.

Samenvattend

… kun je stellen dat er met rollen, redenen, scenario’s en interactiebeschrijvingen niet echt meer van een romantische liefdesbaby gesproken kan worden. Voor een succesvol Scrum-project heb je deze echter heel hard nodig.

Mijn advies: schrijf elke user story ook echt in de vorm van een user story. Schrijf daarbij alle scenario’s uit volgens een SMART notatie en voeg de nodige verduidelijkingen toe. Maak een checklist (Definition of Ready) voor wat er verder beschreven moet worden.

Alleen met goede bouwtekening kan een huis gebouwd worden zoals het bedoeld is. Goed beschreven user stories zijn de bron voor bouwen, testen en inschatten. In mijn volgende blog post zal ik verder ingaan op de verschillende manieren van inschatten.