Welke rol speelt de informatie-specialist in een ontwikkeltraject?

Stel een bestuurder van een organisatie of overheidsinstelling wil een digitale leeromgeving voor de medewerkers. Onze conceptontwikkelaars maken op basis van zijn vraag een concept, dat we aan de klant presenteren.

De stap van concept naar ontwikkelen is veel te groot om in één keer goed neer te zetten. Het concept bevat nog te weinig details over de wensen van de verschillende type gebruikers en mist antwoorden op essentiële vragen. Ontwerpers en ontwikkelaars kunnen nog niet starten.

Op dat moment komt de rol van een informatie-specialist goed van pas. Een informatie-specialist luistert en verzamelt de brokken informatie – van de klant, eindgebruikers, beheerder en andere betrokkenen. Een document wordt opgesteld waarmee het ontwikkelproces wél van start kan gaan. En één van de gereedschappen die vaak gebruikt wordt is het opstellen van user story’s.

En wat is een user story?

Een user story is in een klein verhaaltje waarin kort wordt omschreven waar een specifieke functionaliteit aan moet voldoen. User story’s vertalen het concept tot een pakket aan wensen en behoeftes. Zo kan het team van ontwikkelaars en ontwerpers aan de slag met het ontwikkelen en bouwen van losse functionaliteiten.

User story’s worden in moderne scrum-trajecten of sprints in plaats van een functioneel ontwerp gemaakt. User story’s zijn 

• klein en overzichtelijk
• ze voegen waarde toe
• gaan over één functionaliteit.

User story’s zijn onafhankelijk van elkaar, zodat een ontwikkelteam aan één specifieke functionaliteit kan werken. Bij een functioneel ontwerp wordt alles in één keer, allemaal achter elkaar gebouwd. Dat doen we tegenwoordig niet meer.

Omdat een user story klein en behapbaar is, zie je snel resultaat en kan er snel worden teruggekoppeld en worden bijgestuurd. Dat is fijn om als product owner controle over het eindproduct te hebben.

Het team kan inschatten hoeveel tijd het kost om een user story tot functionaliteit te ontwikkelen en zo een betere planning te maken. De klant of product owner kan bij elke user story terugkoppeling geven. Zo is de klant direct betrokken bij het eindresultaat.

Hoe schrijf je een user story?

In een ideale wereld kan de klant, de product owner een user story schrijven. Hij of zij weet namelijk het beste welke wensen er binnen de organisatie zijn en bij de eigen klanten leven. In de praktijk is dat vaak in coproductie met een informatie-specialist. Bijvoorbeeld omdat de product owner geen tijd heeft of niet goed weet hoe hij of zij dat het beste kan doen.

Laten we starten met wat een user story precies is. 

• is een korte en bondige beschrijving van een functionele wens van een gebruiker;
• is in jip-en-janneketaal geschreven, bij voorkeur door de product owner;
• heeft toegevoegde waarde voor de gebruiker;
• is een discussiestuk (staat niet in beton gegoten).

Dat laatste punt is cruciaal. Een user story is niet zo gedetailleerd dat er vastgelegd is wat er precies gemaakt moet worden. Een user story biedt juist die informatie om over te discussiëren, zodat met het team gezocht kan worden naar de beste oplossing. Een user story is er voor de gebruiker én om aan de wens van de gebruiker te voldoen.

Uit welke onderdelen bestaat een user-story?

Een user story bestaat uit een aantal delen:

• het heeft een pakkende, beschrijvende titel; zodat iedereen weet over welk ‘verhaal’ het gaat;
• het kent duidelijke acceptatiecriteria, een controlelijstje; op basis waarvan je na afloop kunt testen of de vraag goed ingevuld is;
• het vertelt altijd [wie] iets wil, [wat] deze persoon of rol wil bereiken en [waarom] hij of zij dat zo graag wil. 
• Juist het antwoord op de waaromvraag geeft de [toegevoegde waarde] voor de gebruiker aan.

Een voorbeeld

Het inzien van een rooster

Als cursist [wie] wil een overzicht zien welke cursussen [wat] er zijn zodat ik me goed kan voorbereiden [waarde].

Dit wordt afgesloten met de acceptatiecriteria, die bepalen of de uiteindelijke functionaliteit aan de eisen voldoen. Alles past op één post-it. Als dat niet zo is, dan is de user story te groot.

• ik wil een lijst van cursussen zien
• Ik wil kunnen zoeken op titel en competentie
• Ik wil een melding krijgen als er geen resultaten zijn gevonden

Sjabloon voor het schrijven van een user story
 

Als [wie] wil ik [wat] zodat ik [waarom/waarde].

Een aantal tips

• Wees zo specifiek mogelijk als je de [wie] omschrijft. Gebruik geen algemene termen zoals ‘gebruiker’. Je moet weten welke ‘persona’ of groep gebruikers deze wens heeft.
• Gebruik werkwoorden als je de [wat] omschrijft. Dat geeft namelijk aan wat de gebruiker wil bereiken. Dus niet “ik wil een overzicht”, maar “ik wil een overzicht inzien”.
• Wat vaak gebeurt, is dat er niet omschreven wordt ‘waarom’ een bepaalde gebruiker iets wil bereiken, maar ‘hoe’ hij dat wil doen. 
• Probeer niet in die valkuil te stappen. Het beantwoorden van de hoe-vraag laat je namelijk juist aan het ontwikkelteam over.
• Gebruik geen jargon of afkortingen, tenzij daar afspraken over zijn gemaakt. Dat geeft onnodige ruis en geeft soms verwarring.

Methode: INVESTeer in je user story’s

Wil je weten of er een goede user story hebt geschreven? Haal het verhaaltje dan langs deze INVEST-checklist:

Is it Independent?

Zorg dat je user story’s onafhankelijk zijn van andere story’s, zo kan de product owner (de klant) prioriteiten stellen.

Is it Negotiable?

User story’s moeten niet te gedetailleerd zijn. Ontwikkelaars en ontwerpers moeten de vrijheid krijgen om zelf in te vullen hoe een functionele wens vorm krijgt.

Is it Valuable?

De functionaliteit moet uiteindelijk waarde geven voor de gebruiker. Die waarde wordt door de product owner bepaald. De meest waardevolle functionaliteiten worden als eerste ontwikkeld.

Is it Estimable?

Kun je inschatten hoe veel tijd en werk het ongeveer kost om de functionaliteit te ontwikkelen en is alle kennis in huis? Zo niet, dat in de user-story waarschijnlijk te groot.

Is it Small enough?

Is de user story klein genoeg?  Past het op één post-it en beschrijft het maar één functionaliteit? Hij moet ook niet te klein zijn. Als de user-story te weinig waarde heeft, is het slim om meerdere kleine user story’s beter bundelen tot één grotere. Vuistregel: als de inschatting langer duurt dan één of twee dagen om te ontwikkelen, dan is de user-story te groot. Korter dan een uur, dan is ie te klein.

Is it Testable?

Zijn er goede acceptatiecriteria omschreven bij de user story, waardoor je kunt bepalen of de functionaliteit straks aan de eisen gaan voldoen?

Slot: Een goede basis voor blije gebruikers

Kan je op alle bovenstaande vragen ‘ja’ antwoorden; dan vormt jouw verhaaltje of user story een goede basis voor het ontwikkelteam om aan de slag te gaan. 

En het lijkt misschien klein, zo’n kort verhaaltje op een geeltje. Maar als je investeert in het schrijven van goede user story’s, levert dat uiteindelijk een platform of functionaliteit op waar de individuele gebruiker gelukkig mee is, en dagelijks met plezier mee werkt.