Miscommunicatie in softwarespecificaties.

Een ervaring die ik onlangs had

Ik was online aan het wachten om te chatten met een servicemedewerker. Natuurlijk moest ik het eerst doen met een bot, die in mijn geval niet erg behulpzaam was. Na een tijdje werd ik doorverbonden met een echt mens. Terwijl ik wachtte, was dit mijn ervaring in WhatsApp (zie afbeelding). De wachttijd in deze berichten had volgens de tekst de tijd moeten zijn die je nog moet wachten. De ontwikkelaar heeft het blijkbaar geïmplementeerd als de tijd die je al wacht.....

Dat zorgt voor een behoorlijk slechte klantervaring:

1. 1. De klant verwacht zeer snel antwoord te krijgen

1. 1. De klant ontvangt elke minuut een WhatsApp-bericht

Oorsprong van User Stories

In mijn Product Owner training benadruk ik altijd dat de taak van een Product Owner niet het schrijven van betere User Stories is, maar het vertellen van betere verhalen van gebruikers.

User Stories zijn ontstaan toen Kent Beck, de grondlegger van eXtreme Programming (XP), feedback kreeg van een gebruiker die zo enthousiast was over nieuwe functionaliteit dat het idee ontstond om te proberen de reactie van de gebruiker vooraf te definiëren. Wat is de reactie die je hoopt te krijgen van de gebruiker wanneer hij de nieuwe functionaliteit kan gebruiken?

Om het makkelijker te maken, heeft Ron Jeffries er een sjabloon voor gemaakt. Als je werkt met Agile of Scrum, heb je deze waarschijnlijk al gezien.

Als een [type gebruiker]
Wil ik [een bepaalde functie]
Zo dat [een bepaalde waarde]

Ze beschrijven WHO, WAT en WAAROM (let op; niet HOE).

Misbruik van User Stories

De fout die vaak wordt gemaakt is dat dit sjabloon wordt gezien als de nieuwe manier om requirementsspecificaties vast te leggen. Door te proberen eisen vast te leggen in het sjabloon die geen enkele relatie hebben met de gebruiker. Bijvoorbeeld:

Als Developer wil ik een Database zodat ik mijn gegevens kan opslaan.
Als Product Owner heb ik een rapport nodig dat ik aan de CEO kan laten zien.

Hele documenten en tekstblokken worden ook gekoppeld aan items in Jira, TFS, enz.

Daar zijn User Stories niet voor bedoeld, ze zijn de basis voor het verzamelen van Social Requirements, oftewel het voeren van betere gesprekken met elkaar over de gebruikers en functionaliteit tussen ontwikkelaars en gebruikers. Als alternatief voor gebruikers kun je hier ook vertegenwoordigers of ook wel stakeholders voor gebruiken, maar zij moeten de gebruikers echt begrijpen en kunnen vertegenwoordigen.

Als coach van het eerste XP-team introduceerde Ron Jeffries de 3 C's: Kaart, Gesprek en Bevestiging.

• • Kaart: Een indexkaart met titel en een of twee zinnen uitleg.

• • Gesprek: Discussie met het hele team over wat gewenst is

• • Bevestiging: Leg vast hoe wordt bepaald of het voldoet

User Stories hoeven niet perfect gedefinieerd te zijn voordat het gesprek met het team plaatsvindt. Tijdens de #BacklogRefinement kan de definitie van de User Story worden aangepast en kunnen Acceptatiecriteria worden herschreven of toegevoegd.

Hoe we kunnen helpen

Als je geïnteresseerd bent in betere gesprekken, bekijk dan onze Workshop User Story Mapping

We zullen dit ook bespreken in onze Certified Scrum Product Owner zie ons schema hieronder.