Miscommunicatie in softwarespecificaties.

Er zijn vaak misverstanden in softwarespecificatiedocumenten. De oplossing die we meestal kiezen is om meer gedetailleerde specificaties te maken. Helaas leidt dat niet tot betere resultaten.
Je kunt deze post ook lezen in

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. De klant verwacht zeer snel antwoord te krijgen

    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.

 

Delen:

Gerelateerde blogposts

Verhoog uw SAFe® door barrières te slechten

Impact van Hiërarchische Grenzen op SAFe® Scaled Agile Framework Adoptie In het streven naar organisatorische agility wordt vooral gedacht dat Scaled Agile Framework (SAFe®) een roadmap biedt voor...

Miscommunicatie in software specificaties.

Er zijn vaak misverstanden in software specificatiedocumenten. De oplossing die we meestal kiezen is om meer gedetailleerde specificaties te maken. Helaas leidt dat niet tot betere resultaten.

Gerelateerde training

Verwante bronnen

Hoe voer ik een Retrospective uit?

Het uitvoeren van een effectieve retrospectieve is cruciaal voor continue verbetering in Agile teams. Als je ooit het gevoel hebt gehad dat de retrospectives van je team richting missen of geen bruikbare inzichten opleveren, dan...

Een cirkelvormig stroomdiagram met verschillende stadia die het scrumproces voorstellen

Het Scrum proces uitgelegd

Ontdek de fijne kneepjes van het Scrum proces en leer hoe dit agile framework een revolutie teweeg kan brengen in projectmanagement.

Een telescoop die gericht is op een verre

Wat is een productvisie? .

Ontdek de kracht van een productvisie en hoe deze de toekomst van een bedrijf vormgeeft.

Meer berichten

We kunnen meedenken
hoe we kunnen helpen!

Vind je onze artikelen leuk? Nog beter, je kunt ons persoonlijk spreken! Neem contact met ons op zodat we iets kunnen plannen!