User Stories: 7 signalen dat het een zooitje is

7 signalen dat het een zooitje is met de user stories

Veel organisaties die overgaan op het Agile ontwikkelen van software starten met het schrijven van user stories en stoppen met het vastleggen van requirements in dikke documenten. Dit vaak tot groot genoegen van zowel de mensen die deze uitgebreide documenten moesten maken als de mensen die ze moesten lezen.

Immers, user stories hebben onder andere de volgende voordelen :

  • Ze leggen de nadruk op mondelinge communicatie en discussie.
  • Ze worden daarom beperkt en in een eenvoudig formaat beschreven:

Als …,
wil ik …,
zodat …

  • Ze kosten veel minder tijd, want ze hoeven (nog) niet allemaal tot in detail uitgewerkt te worden.


Wat kan er mis gaan zou je zo zeggen
. Nou een hele hoop.

Laten we eens naar zeven signalen in de praktijk kijken waaruit blijkt dat het werken met user stories niet efficiënt en effectief is. Kortom, dat het een zooitje is geworden.

  1. Nog steeds aannames en misverstanden
    Vooral bij organisaties die (nog) niet volledig Agile werken zie je gebeuren dat wensen en eisen wel in het formaat van user stories worden opgeschreven, maar dat ze vervolgens aan anderen worden overhandigd om ze verder uit te werken en/of te ontwikkelen. Zonder de bijbehorende mondelinge toelichting en discussie.

    En dan krijg je precies hetzelfde effect als voorheen bij de dikke requirements documenten, namelijk dat de lezer het geschrevene anders begrijpt en interpreteert dan de schrijver heeft bedoeld. En dat er iets anders wordt opgeleverd dan werd verwacht.

  1. Heel erg veel user stories
    Ook zijn er teams die worden overladen met user stories op de product backlog. Werkelijk alle ideeën komen erop terecht. Zo hoorde ik laatst van een deelnemer aan mijn training dat zijn team gemiddeld met zo’n 3000 (!) user stories te maken heeft.

    Een overdosis aan user stories leidt er echter toe dat er heel veel tijd verloren gaat aan sorteren, ordenen, prioriteren en discussies over stories die nu nog helemaal niet relevant zijn (en dat misschien ook helemaal niet worden).

  1. Steeds weer verrassingen tijdens demo’s
    Hoor je iedere keer pas tijdens de demo opmerkingen als:

    “Jullie zijn dit of dat helemaal vergeten mee te nemen.”
    “Oh, maar dat mag helemaal niet volgens de wet!”
    “Het is wel erg traag allemaal.”

  1. Meereizende user stories
    Dit zijn user stories die steeds weer doorgeschoven worden naar de volgende sprint, iteratie of release. Vaak omdat de story (nog steeds) te groot blijkt te zijn of omdat er weer nieuwe vragen of ideeën naar boven, waardoor het voor het team onduidelijk is wat wel en wat niet ontwikkeld moet worden en het dus niet binnen de tijd kan worden opgepakt.
  1. Te weinig analyse
    Er zijn ook teams die zo graag Agile én lean willen werken, die zo graag af willen van al die dikke documenten, dat ze daarin totaal doorschieten en de analyse van product, context, stakeholders en de user stories maar gelijk helemaal afschaffen.

    Zo zei een manager van een ontwikkelafdeling eens tegen mij: “Wij gaan scrummen, dus wij hebben straks geen requirements en documenten meer.”

    Te weinig analyse leidt niet alleen tot problemen en veel onduidelijkheid in de sprint, maar vaak ook nog eens tot het verzamelen en implementeren van de verkeerde user stories.

  1. Slecht blijven schatten
    Wanneer development teams, ook wanneer ze al maanden bij elkaar zijn, keer op keer de complexiteit en grootte van user stories verkeerd inschatten. Vaak omdat er structureel cruciale informatie ontbreekt, waardoor user stories tijdens de sprint veel complexer en veel groter blijken dan gedacht en niet (allemaal) binnen de sprint opgeleverd kunnen worden.

    En dit leidt dan vaak weer tot…

  1. Zeer langdurige planningsessies


Samengevat
, om succesvol te werken met user stories is meer nodig dan het implementeren van een Agile werkwijze en een user story template . De 7 problemen zijn signalen van het ontbreken van:

  • Een heldere analyse en product visie.
  • Een product owner die heel vaak NEE durft te zeggen (of niet nu).
  • En gestructureerde discussies vóór de start van de sprint waarbij technieken worden gebruikt om cruciale informatie te verzamelen om de complexiteit en grootte van elke user story helder te krijgen.

Zijn deze signalen voor jou herkenbaar in jouw eigen situatie? Of zijn er voor jouw nog andere signalen dat het werken met user stories niet optimaal verloopt?  Je kunt hieronder jouw reactie achterlaten.

Vind je dit artikel waardevol? Deel het dan met anderen voor wie het ook interessant kan zijn, bijvoorbeeld via Facebook, Twitter, LinkedIn of Google+.  Alvast hartelijk dank daarvoor!

, ,

No comments yet.

Leave a Reply