User stories bespreekbaar of als overeenkomst?

In het vorige artikel werd duidelijk hoe afhankelijkheden tussen user stories vermeden kunnen worden en wat mogelijke oplossingen zijn om afhankelijke user stories te splitsen. Use case technieken komen hier handig van pas. In deze blog ga ik verder in op het ezelsbruggetje “INVEST” van Bill Wake. Dit ezelsbruggetje kan in gedachten gehouden worden bij het vormen van goede user stories. Het tweede karakter (N) staat voor “Negotiable” en staat centraal in deze blog.

Allesomvattende documentatie en onderhandelingen

Voor de komst van de agile projectaanpak ging de traditionele aanpak, die ook wel waterval wordt genoemd, uit van een strak geplande opvolging van werkzaamheden in silo’s van specialisten. In deze aanpak was het doel om de wensen en eisen van opdrachtgevers te vatten in stukken allesomvattende documentatie. In deze “specificatiefase” van het project ontstond er zelf een intensieve onderhandeling van details die in of buiten de design scope hoorde. Een dergelijke aanpak zorgt voor veel onvoorspelbaarheid en features met een open einde. Delen van het systeem werden niet afgemaakt of bevatten een aanzienlijke hoeveelheid fouten t.o.v. het ontwerp (technical debt).

Met de komst van agile en het werken in multidisciplinaire teams ontstond een aanpak waarin samenwerken centraal staat. Toch gebeurt het in een agile aanpak nog regelmatig dat grote onderdelen van het systeem vooraf in detail worden ontworpen. Het gevolg hiervan is dat er geen concentratie meer is op de essentie van de backlog items ofwel user stories. Teams lopen uit omdat de gedetailleerde features opgeleverd worden volgens de allesomvattende requirenments.

Er zijn meerdere manieren om een user story van teveel detail te voorzien tijdens een agile traject. Er zijn projecten die vooraf volledig worden gespecificeerd tot in de details waarna de ontwikkelfase wordt ingevuld met een iteratief karakter. Een andere manier is om een voorlopende sprint te creëren voor iedere ontwikkelsprint waar de analisten en UX specialisten de user stories voorbereiden. Deze aanpak is nodig om het ontwikkelteam snel op gang te krijgen en het planningpoker (bepalen van de complexiteit) proces zo vlot mogelijk te laten verlopen. Deze aanpak werkt goed in bepaalde industrieën maar is niet zonder gevaar omdat teveel detail kan worden aangebracht in deze voorlopende sprints.

Customer collaboration over contract negotiation

Working software over comprehensive documentation

Responding to change over following a plan

Het aanbrengen van teveel detail gaat tegen drie van de vier principes in van het agile manifesto (zie hierboven). Door het willen vastleggen van details onstaat er namelijk een onderhandeling (contract negotiation). Een deel van het team steekt energie in het opstellen van specificaties en wireframes wat kan worden beschouwd als afval (geen werkende software). Eenmaal aangekomen in een ontwikkelsprint is het team niet inventief meer om oplossingen op een andere manier te implementeren om zo het doel van de iteratie te halen. Er wordt blind gekeken naar de opgestelde requirements en acceptatiecriteria.

User stories voldoen aan de drie C’s

User stories zijn veel toegepast binnen agile trajecten al is het geen must. De belangrijkste doelen van user stories zijn de herkenbaarheid van een gewenst gedrag van het systeem (referentie) en het ondersteunen van de conversatie hierover. User stories zijn geen overeenkomst tussen opdrachtnemer en opdrachtgever waarin precies staat wat de details zijn van de gewenste functionaliteit. De user stories bevatten net genoeg detail om ze in de ontwikkelsprint te kunnen bouwen. Belangrijke details worden opgenomen als annotaties bij een user story.

Om deze belangrijke eigenschappen  toe te kunnen passen is ook hier een ezelsbruggetje bedacht door Ron Jeffries.

User stories have three critical aspects. We can call these Card, Conversation, and Confirmation.

Card

User stories zijn geschreven op het formaat van een kaart (post-it). Deze post-it bevat niet alle informatie van de requirement maar dient ter identificatie om te kunnen plannen, de volgorde op de backlog te bepalen, de complexiteit te kunnen bepalen en de status duidelijk te maken tijdens ontwikkeling.

Conversation

Requirements bestaan vooral in de vorm van conversaties tussen klanten, product owners, ontwikkelaars, designers, interactiondesigners, testers en andere disciplines die betrokken zijn in een multidisciplinair team. De requirements zijn voor het grootste gedeelte verbaal maar kunnen ook de vorm aannemen van documenten als wireframes, use cases, design voorstellen, klikdemo’s en andere vormen van requirementsdocumentatie. Het is echter de kunst om zo weinig mogelijk documenteatie toe te voegen zodat het team de requirement kan bouwen.

Confirmation

Om user stories naar een done status te krijgen moet er duidelijkheid bestaan wanneer een user story af is. Deze bevestiging kan worden geborgd door de acceptatiecriteria. Indien het nodig is om naast acceptatiecriteria overige vormen van documentatie te hanteren dan is dit mogelijk. Aan het einde van een ontwikkelsprint wordt er inzichtelijk gemaakt dat er wordt voldaan aan de vooraf gedefinieerde acceptatiecriteria. Door het hanteren van acceptatiecriteria komen de kaart en conversatie bij elkaar.

Acceptatiecriteria in de praktijk

Het werken met user stories is niet eenvoudig. Er ontstaat snel een gevaar dat er teveel details worden vastgelegd in annotaties en requirementsdocumenten waardoor het project een waterval karakter krijgt. Specialisten binnen een team houden nu eenmaal voor een deel vast aan bewezen en bekende tools en methoden om requirements inzichtelijk te maken (functionele beschrijvingen, testscripts, wireframes en designs zijn enkele voorbeelden). Ook vanuit de business owner bestaat het gevaar dat er teveel details worden verzameld als het nog niet eens duidelijk is of de requirements voldoen aan de visie van het product. Het is aan de business owner om de acceptatiecriteria te vormen die concreet beschrijven wanneer de uitwerking voldoet aan de wensen en eisen van de business unit. Het schrijven van deze criteria vereist ook enkele expertise die vaak ontbreekt.

Een mogelijke oplossing voor deze problemen is om de businessowners te trainen in deze aanpak. Het bijbrengen van de principes van de Use Case 2.0 methode en het opstellen van acceptatiecriteria is een vereiste om de backlog eenduidig en solide te vormen.

Use cases als acceptatiecriteria

Use cases in de essentiele vorm worden ook wel use case narratives genoemd. Deze vorm beschrijft op het juiste niveau de high level werking van een user story. User stories beschrijven het doel van een onderdeel van een systeem en wie het initiatief neemt (rol of persona). Use cases beschrijven hoe dit doel bereikt wordt. Naast het vastleggen van de high level requirements dient de use case narrative voor een aantal acceptatiecriteria. De interactie van het systeem met de eindgebruiker kan hiermee geverifieerd worden. Als de use case echter vanuit een te laag niveau is geschreven (sub-functioneel) ontstaan er weer teveel details die voor teveel werk zorgen tijdens de ontwikkeling.

Samenvattend

User stories kunnen gebruikt worden om de conversatie te ondersteunen. Acceptatiecriteria bevestigen de werking van de user story. Use case narratives kunnen gebruikt worden om een deel van de acceptatiecriteria te vormen. Deze acceptatiecriteria zullen door de businessowner aangedragen moeten worden. Het risico is groot dat user stories naast de conversatie en acceptatiecriteria vormen krijgen van detailuitwerkingen. Hierdoor kan het team niet meer inventief bijsturen om een sprintdoel te halen en ontstaat er ‘waste’. Iets vooruit werken om belangrijke details te vatten is noodzakelijk maar kan snel omslaan naar een waterval karakter.

In een eerdere blog is er al ingegaan op de waarde van user stories wat het derde karakter is in het ezelsbruggetje. In de volgende blog wordt er ingegaan op de inschatting van een team.

[bol_bestsellers limit=”4″ block_id=”bol_53d179ae2e97a_bestsellers” cat_id=”22″ name=”Relevante boeken” sub_id=”” title=”” link_color=”003399″ subtitle_color=”000000″ pricetype_color=”000000″ price_color=”CC3300″ deliverytime_color=”009900″ background_color=”FFFFFF” border_color=”D2D2D2″ width=”605″ cols=”4″ show_bol_logo=”0″ show_price=”0″ show_rating=”0″ show_deliverytime=”0″ link_target=”1″ image_size=”1″ admin_preview=”1″]