User stories zijn een tool die zijn oorsprong vindt in Extreme Programming en zijn de de facto manier geworden waarop Agile teams hun requirements documenteren en verzamelen. Er is veel geschreven over user stories (link, link, link), dus ik ga het alleen hebben over wat ik belangrijk vind in het schrijven van goede stories, omdat ik veel slechte stories zie vandaag de dag.
Voor degenen die het niet weten, stories zijn een lichtgewicht artefact dat ons in staat stelt om zowel de behoeften van de business vast te leggen EN het werk te plannen. Ze worden meestal geschreven op index kaarten (ja … kleine 3 × 5 of 4 × 6 kaarten) in de taal van het bedrijf of de klant. Met user stories, schrijven we alleen genoeg om de behoeften van de gebruiker vast te leggen en niet meer. We hebben de neiging om stories niet te zien als een volledige specificatie van de requirements, maar als plaatshouders voor latere gesprekken tussen de ontwikkelaars en de business.
Wanneer goed gebruikt, biedt het gebrek aan detail van een user story ons een grote mate van bruikbaarheid – we kunnen hetzelfde document gebruiken om te praten over een requirement vanaf een hoog niveau, inzoomen op implementatie details en weer eruit springen, allemaal in de loop van een paar zinnen. Als we dan klaar zijn met praten over de vereisten, kunnen we risico’s overwegen, afhankelijkheden identificeren en een projectplan maken zonder ooit de indexkaart te hoeven neerleggen. Wow !! Ik ken geen andere requirements artefacten die ons een dergelijk nut bieden.
Door de jaren heen hebben mensen die echt succesvol zijn met stories zich gevestigd op een aantal gemeenschappelijke kenmerken die in alle stories te vinden zijn:
- Rol: wie, of wat, gaat deze feature gebruiken?
- Feature (of capability): wat gaat het Team leveren, of toevoegen, nadat ze klaar zijn met hun werk?
- Waarde: waarom wil de business deze feature eigenlijk hebben? Welke impact zal het hebben op de business?
- Acceptatie criteria: hoe weten we of deze feature af is?
- Schatting: hoeveel denkt het team dat deze feature gaat kosten?
IMO, om een story als compleet te beschouwen moet het ALLE kenmerken hebben die hierboven zijn beschreven. Ik vind dat wanneer mensen moeite hebben met het definiëren van alle kenmerken, de stories niet wat ik noem rijp zijn, d.w.z. ze zijn niet goed genoeg doordacht om bruikbaar te zijn voor het Team. Naast deze kenmerken moeten stories ook voldoen aan de INVEST criteria (dit geweldige artikel van J.B. Rainsberger gaat ook over INVEST).
Mike Cohn heeft een geweldig boek geschreven over user stories. Helaas, voor al het goede in het boek, lijken mensen zich te hebben geconcentreerd op dat ene beetje troep in het boek – de user story template. In zijn boek biedt Mike een sjabloon aan dat sommige teams nuttig vonden bij het schrijven van verhalen, en vanaf dat punt is dit sjabloon de bron geweest van zoveel slechte verhalen dat ik het geen inkt (of stukjes) meer ga geven. Wat mij tegenstaat aan het sjabloon is dat het ervoor zorgt dat mensen stoppen met nadenken terwijl ze mechanisch rol, kenmerk en waarde invullen en acceptatiecriteria en schatting weglaten (vermoedelijk omdat die ontbreken in het sjabloon). Als ik mensen zie worstelen met stories, dan is dat omdat ze proberen hun business in een of ander sjabloon te proppen dat een naamloos team (dat dit sjabloon waarschijnlijk niet eens meer gebruikt) vijf of zes jaar geleden heeft geholpen en – verrassing – het past niet waar ze nu staan.
Er is een denkproces dat moet plaatsvinden voordat je ook maar één story schrijft. De stappen die ik meestal zie mensen voltooien die zijn succesvol schrijven van verhalen zijn hieronder opgesomd. Houd in gedachten, terwijl deze stappen zijn lineair in mijn bericht, kan men springen terug, vooruit en overslaan rond als het zinvol is. Het doel is om deze vragen beantwoord te hebben tegen de tijd dat je klaar bent met je verkenning van je user story.
- Wat zijn de rollen (of gebruikers) die je systeem gaan gebruiken?
- Wat zijn hun behoeften? Hoe helpt het product hen dat te bereiken?
- Welke features (of mogelijkheden) wil je deze rollen bieden?
- Waarom zijn deze features waardevol voor het bedrijf? Wat voor soort bedrijfsresultaten kunnen we van deze functies verwachten?
- Wat zijn de prioriteiten van deze functies? Hebben we een belofte gedaan om sommige al op te leveren?
- Hoe weet je of deze features klaar zijn?
Ten slotte hebben mensen de neiging om een heleboel details op de voorkant van de story card te willen schrijven. Ik heb twee suggesties voor deze mensen. Ten eerste, gebruik kleinere kaarten – echt waar. User stories zijn GEEN specificaties of requirements documenten. Het zijn gewoon index kaarten die de behoeften van de gebruiker vastleggen en herinneringen dat we die implementatie details later moeten vastleggen. Als je steeds meer op een kaart probeert te proppen, kan dat een teken zijn dat je specificaties of een soort ontwerpdocumentatie nodig hebt in aanvulling op de user stories. Ten tweede, het soort details dat mensen proberen op te schrijven zijn eigenlijk acceptatiecriteria. Door die details in de testcases te duwen, houden we het verhaal in de taal van de business en behouden we de focus op de functie en de waarde die je team levert.