Een Gids Voor het schrijven van effectieve gebruikersverhalen

hoe schrijven we effectieve gebruikersverhalen?

er zijn 5 leidende principes die ik als volgt aanraad:

1. iedereen zou blij moeten zijn
   iedereen aan boord krijgen is belangrijk, dus zorg dat iedereen die jouw gebruikersverhalen schrijft en gebruikt hun ideeën invoert en het eens wordt over het formaat dat jullie allemaal zullen gebruiken.
2. Wees consistent
   als je eenmaal een overeengekomen structuur hebt, zorg er dan voor dat je je eraan houdt.
3. Focus op wat belangrijk is
   wanneer u ze uitschrijft, vermijd onbelangrijke details., Neem de tijd om ze beknopt te maken, verwijder elke wafel als het gewoon in de weg.
4. geen implementatiedetails
   richt zich altijd op het “waarom” en niet op het”hoe”. Waarom wil een gebruiker iets, niet hoe gaan we het bouwen. Als u technische details moet verstrekken, moeten deze als apart spec-bestand worden bijgevoegd.
5. duidelijk, haalbaar & testable
   Zorg ervoor dat iedereen elk verhaal kan begrijpen en dat het haalbaar is in het tijdsbestek waar u tevreden mee bent. Als je het leveren van in 2 weken sprints, dan moet het niet langer duren dan die 2 weken.,

gebruikersverhaal anatomie

Er zijn 3 verplichte delen voor een gebruikersverhaal, de titel, beschrijving en acceptatiecriteria. Je team kan het ermee eens zijn dat een gebruikersverhaal andere velden moet hebben voordat het werk eraan kan beginnen. U kunt bijvoorbeeld een cessionaris, story points of de zakelijke impact vereisen, maar ik beschouw deze als optioneel omdat niet elke organisatie deze nodig heeft.

Titel
titels moeten kort, uniek en niet misleidend zijn.,

enkele goede voorbeelden:

• “Add contact us panel to home page”
• “add debit card support to shopping cart”
• “update email template tagging”

enkele minder goede (helaas echte wereld) voorbeelden:

• “Make agreement changes”
• “32072 — Updated Mapping – Upsell User story (27263)”
• “links — tracking query string for bill trigger and smart post install …”

beschrijving

de beschrijving bevat de echte kracht van het gebruikersverhaal. Het zou empathie moeten creëren in het team voor de gebruiker en inzicht in het probleem dat moet worden opgelost.,

een zeer populaire structuur voor de beschrijving neemt de vorm aan van “As A … I want … so I can …”.

Deze structuur roept de vraag op van “as a who”? Wie is de gebruiker die met het probleem wordt geconfronteerd? Je zou hier naar een persona kunnen verwijzen als je ze gebruikt, als alternatief, geef de gebruiker een naam en voeg wat context toe aan de situatie van de gebruiker. Probeer het gebruik van “als klant” of “als gebruiker” te vermijden, omdat dit minder effectief is in het creëren van empathie voor een werkelijke gebruiker.

de beschrijving moet in eenvoudige, duidelijke taal worden geschreven, zonder technische termen of afkortingen., Je moet jezelf afvragen ” kan je Oma het begrijpen?”Een nieuw teamlid moet de beschrijving kunnen lezen en precies begrijpen wat het probleem is dat moet worden opgelost.

de volgende concrete voorbeelden zijn ontleend aan een project om functionaliteit toe te voegen aan een online accountsysteem voor klanten van een energiebedrijf in het Verenigd Koninkrijk.,

enkele goede voorbeelden:

• “als John, een klant met een traditionele elektriciteitsmeter, wil ik begrijpen waarom ik geen diagrammen van mijn energieverbruik meer in detail kan zien dan maand voor maand, zodat ik kan beslissen of ik dit wil veranderen en een slimme meter wil installeren.”
• ” als Bart, een proactieve traditionele meterklant die ervoor wil zorgen dat mijn volgende factuur accuraat is, wil ik weten of er vandaag al een meterlezing is ingediend en dat ik geen andere hoef in te dienen.,”

enkele minder goede voorbeelden:

• “als gebruiker wil ik voorkomen dat klanten van trad onder het hoogste niveau kunnen boren zodat hun klantervaring wordt beheerd”
• “als klant die vandaag een meteruitlezing heeft verstrekt of vandaag een geschatte brandstofuitlezing heeft gehad, mag ik vandaag geen andere meteruitlezing indienen omdat SAP niet meer dan één meteruitlezing per brandstof per dag kan accepteren.”

de minder goede voorbeelden werden eigenlijk herschreven om de goede voorbeelden hierboven te zijn, omdat de problemen die zij beschreven niet duidelijk waren., Deze verfijning proces moet worden gedaan op elk moment een deel van een gebruiker verhaal is niet duidelijk. Zorg ervoor dat iedereen in het team op de hoogte is en akkoord gaat met de veranderingen.

acceptatiecriteria

acceptatiecriteria worden gebruikt om de volledigheid van het gebruikersverhaal te bewijzen. Dit is nuttig voor ontwikkelaars en testers.

het schrijven van de acceptatiecriteria is een effectieve manier om alle details van het verhaal door te nemen voordat u met een werk begint. Veel potentiële valkuilen of onverwacht werk kan vroeg worden “ontdekt” door het schrijven van goede acceptatiecriteria.,

een zeer populaire structuur voor de acceptatiecriteria neemt de vorm aan van “gegeven… wanneer… dan…” zoals te zien is in de onderstaande voorbeelden.

als een gebruikersverhaal meer dan 10 acceptatiecriteria heeft, kan het een indicatie zijn dat het verhaal te veel dingen doet. In dit geval raad ik aan om het verhaal te splitsen.

het hele team moet worden betrokken bij het opstellen van de acceptatiecriteria. Als dit niet mogelijk is, Ik beveel iedereen leest en stemt in met hen voordat u aan hen werkt. Dit geldt met name voor iedereen die betrokken is bij het testen van het werk.,

nummering van de acceptatiecriteria maakt het gemakkelijk om ernaar te verwijzen.

enkele goede voorbeelden:

1. gegeven een klant met een traditionele meter op het staafdiagram van het energieverbruik
   Wanneer een maand op de gereedschapstip
   wordt geklikt, wordt een pop-up weergegeven die overeenkomt met het opgegeven ontwerp.
2. gegeven een dual-fuelklant die het staafdiagram voor energieverbruik bekijkt
   wanneer hij maanden heeft met geschatte waarden
   , moet de diagramlegende duidelijk een geschat elektriciteitspictogram met een lichtrode Balk
   tonen dan moet de diagramlegende duidelijk een geschat gaspictogram met een lichtblauwe balk weergeven.,

wanneer we geen gebruikersverhalen nodig hebben

technische taken

soms lijkt een technische taak geen relatie te hebben met een klant. Als dit het geval is, gebruik dan geen gebruikersverhaal. Maar het is altijd de moeite waard om te overwegen waarom je een technische taak doet; ben je een bibliotheek aan het upgraden om de snelheid voor gebruikers te verbeteren? Zo ja,dat moet een gebruiker verhaal.

Bugs

als een bug wordt gevonden tijdens het testen van een gebruikersverhaal waaraan momenteel wordt gewerkt, dan moet het worden geassocieerd met dat gebruikersverhaal.,

Als er een bug is gevonden voor iets dat niet een huidige gebruiker verhaal, dan moet het niet worden gekoppeld aan een gebruiker verhaal, maar toegevoegd aan de reserve als een zelfstandige taak.

continue verbetering

gebruikersverhalen zullen evolueren naarmate meer wordt geleerd over het werk dat moet worden gedaan. Dit is goed, blijven ze te verbeteren tot het punt dat u het werk vrij te geven aan gebruikers., Zorg ervoor dat iedereen in je team op de hoogte is en akkoord gaat met eventuele wijzigingen die worden aangebracht.

blijf het proces verfijnen. Wees flexibel, denk na over hoe je gebruikersverhalen werken voor je team, bespreek ze in retro ‘ s en blijf de manier waarop je ze schrijft verbeteren.