Dit artikel is gepubliceerd op Frankwatching
Als je een nieuw systeem gaat ontwikkelen, zoals een website, DLWO (digitale leer- en werkomgeving) of zorgportaal, dan is daar een heel team van experts bij betrokken. Niet alleen de welbekende developers & designers, maar ook conceptontwikkelaars, architecten én informatie-analisten. Tot die laatste groep specialisten behoor ik.
Welke rol speelt de informatie-analist in een ontwikkeltraject?
Ik krijg vaak de vraag welke rol ons specialisme speelt in een ontwikkeltraject. Want wat dóen informatie-analisten nu eigenlijk? Stel, een bestuurder van een onderwijsinstelling wil een DLWO voor zijn studenten. Onze conceptontwikkelaars maken op basis van zijn vraag een concept, dat we aan de klant presenteren.
Maar de stap van concept naar ontwikkelen is veel te groot om in één keer te zetten. Het concept heeft namelijk nog te weinig details over de wensen van de eindgebruikers en mist antwoorden op belangrijke vragen. Ontwikkelaars kunnen dus nog niet aan de slag.
Daar komt de informatie-analist om de hoek kijken. Wij verzamelen een hoop informatie – van de klant, eindgebruikers en andere specialisten – en verwerken dat tot een document waarmee het ontwikkelproces wél van start kan gaan. Eén van de ‘tools’ die we daarvoor vaak gebruiken, is de user story.
In de spotlights: de user story
Een user story is in feite een klein verhaaltje waarin kort wordt omschreven waar een specifieke functionaliteit aan moet voldoen. User stories vertalen het concept voor een systeem tot een pakket aan wensen en behoeftes. Daarmee kan een team van ontwikkelaars aan de slag met het bouwen van losse functionaliteiten.
User stories worden in moderne agile-trajecten vaak in plaats van een functioneel ontwerp gemaakt. Waarom is dat eigenlijk zo?
- User stories zijn klein en overzichtelijk en ze voegen ieder waarde toe. Een user story gaat maar over één functionaliteit.
- User stories zijn bovendien onafhankelijk van elkaar, dus ontwikkelteams kunnen los van elkaar één specifieke functionaliteit ontwikkelen. Bij een functioneel ontwerp wordt alles in één keer, allemaal achter elkaar gebouwd.
- Omdat ze zo klein zijn, zie je snel resultaat en kun je snel terugkoppelen en bijsturen.
- Je kunt goed inschatten hoeveel tijd het kost om een user story tot functionaliteit te ontwikkelen en daarmee een betere planning maken.
- De klant kan bij elke user story en bij elk stukje functionaliteit terugkoppeling geven. Zo is de klant veel meer betrokken bij het eindresultaat.
Hoe schrijf je een goede user story?
In de ideale wereld zou de klant, de product owner, user stories schrijven. Hij weet immers het beste welke wensen er binnen de organisatie en bij de eigen klanten of gebruikers zijn. Maar in de praktijk wordt het vaak door de informatie-analist gedaan. Meestal omdat de product owner er geen tijd voor heeft, of niet goed weet hoe het moet. Terwijl het schrijven van een goede user story niet moeilijk hoeft te zijn.
Laten we beginnen met uitleggen wat een user story precies is. Een goede user story:
- is een korte, bondige beschrijving van een functionele wens van een gebruiker;
- is in gebruikerstaal geschreven, bij voorkeur door de product owner;
- heeft altijd toegevoegde waarde voor de gebruiker;
- is een discussie-stuk (en geen contract).
Dat laatste punt is erg belangrijk. Een user story is niet zo gedetailleerd dat er vastgelegd is wat er precies gemaakt moet worden. Een goede user story biedt voldoende informatie om over te discussiëren, zodat samen gezocht kan worden naar de beste oplossing om functioneel aan de wens van de gebruiker te voldoen.
De componenten van een user story: wie, wat en waarom?
Een goede user story bestaat verder uit een aantal componenten:
- het heeft een pakkende, goed beschrijvende titel, zodat iedereen weet over welk ‘verhaal’ het gaat als erover gepraat wordt;
- het kent duidelijke acceptatie-criteria, op basis waarvan je na afloop kunt testen of de vraag goed ingevuld is;
- het vertelt altijd wie iets wil, wat deze persoon wil bereiken en waarom hij of zij dat wil. Het antwoord op de waarom-vraag geeft de toegevoegde waarde voor de gebruiker aan.
Een voorbeeld