Ook last van afhankelijkheden tussen user stories?
Deze website doet vermoeden dat alleen use cases worden behandeld. Aangezien ik mij niet wil beperken in één enkele vorm van requirement engineering maak ik regelmatig een stapje naar andere vormen zoals deze keer user stories. Op het web is veel te vinden over use cases versus user stories en waarom de ene methode beter is dan de ander. Ik ben van mening dat het allebei goede methoden zijn die ook nog eens tegelijk te gebruiken zijn.
Een ezelsbruggetje voor goede user stories
Goede user stories voldoen aan een aantal eigenschappen.
Independent
Negotiable
Valuable
Estimatable
Small
Testable
Deze eigenschappen vormen ook nog eens het ezelsbruggetje “INVEST”. Bill Wake heeft hierover geschreven in zijn blog.
Onafhankelijke user stories en use case include (independent)
Zover het mogelijk is moeten user stories onafhankelijk van elkaar te realiseren zijn. Als er een sterke afhankelijkheid bestaat tussen stories ontstaan er planningsproblemen en het stellen van prioriteiten tussen stories wordt moeilijker. Stel je voor dat er drie stories bestaan:
- Als klant wil ik een klacht kunnen doorgeven
- Als klant wil ik een vraag kunnen stellen
- Als klant wil ik een compliment kunnen geven
Alle stories kunnen met een vergelijkbaar formulier worden verstuurd. De eerste user story die het team tegenkomt zal een hoge inschatting (in punten of uren) onvangen en de overige twee een lage inschatting omdat de basis al is gelegd in de eerste story. De volgorde van deze stories kan niet meer veranderd worden omdat de eerste story de basis bevat voor de overige stories. Dit kan voorkomen als de product owner bepaalt dat het stellen van een vraag meer waarde toevoegt dan het maken van een klacht.
Zoals Mike Cohn in zijn boek “User Stories Applied” beschrijft zijn er twee manieren om hier vanaf te komen.
- Combineer de afhankelijke user stories tot één grotere user story
- Probeer een andere manier om de stories te splitsen in kleinere stories
De eerste optie kan een oplossing zijn bij kleinere user stories. De tweede is vaak lastiger omdat hier de intentie van de user story verloren kan gaan. Een voorbeeld oplossing in de tweede aanpak is het herschrijven naar de volgende stories:
- Als klant wil ik één soort feedback kunnen geven richting de organisatie
- Als klant wil ik twee soorten feedback kunnen geven richting de organisatie
Use cases bevatten hetzelfde probleem. Er is echter een manier om een splitsing te maken binnen use cases. Door via een dieper niveau op de use case in te gaan (sub-functioneel niveau) komen technische handelingen aan het licht. Deze sub-functionele use cases zijn alles behalve onafhankelijk maar zorgen ervoor dat de use cases met een gebruikersdoel (klacht doorgeven, vraag stellen, compliment geven) weer de juiste inschatting kunnen krijgen. De sub-functionele use case zal echter altijd voor moeten gaan op één van de gebruikersdoel use cases.
Hieronder het UML use case diagram voor deze situatie waar de sub-functionele use case “feedback versturen” is afgeleid. Hier is te zien dat iedere use case een include relatie heeft met de sub-functionele use case.
De afgeleidde sub-functionele use case en de include relatie
Include relaties worden gebruikt om sub-functionele elementen te extraheren die voorkomen in meerdere use cases. De sub-functionele use case kan niet op zichzelf waarde toevoegen. Use cases gemaakt zonder de sub-functionele use case zijn niet af.
Deze sub-functionele use case kan ook weer in het user story formaat worden geschreven om weer een plek in te nemen op de backlog. Het doel van deze story komt echter niet meer vanuit de gebruiker maar vanuit de organisatie die baat heeft bij de respons van de formulieren. Bijvoorbeeld:
- Als customer service medewerker wil ik dat feedback vanuit klanten wordt verstuurd zodat hier een opvolging aan gegeven kan worden
En verder?
In mijn volgende blog zal ik de volgende eigenschap behandelen (Negotiable).
