Story

…vele zaken moeten aangepakt en gerealiseerd worden om het doel te bereiken.

✣  ✣  ✣

Een heldere beschrijving van de gewenste resultaten en glasheldere acceptatiecriteria maakt het werk behapbaar en verdeelbaar over vele handen.

De wens van een klant, verteld tijdens een planningsspel, geschat op moeilijkheid door ontwikkelaars, uit te werken in een of meer sprints.

Daarom:

Schrijf het gewenste resultaat op als een beknopt verhaal met een aantal glasheldere acceptatiecriteria. Maak de story implementeerbaar binnen één sprint. Bepaal tijdens het planningsspel aan het begin van elke sprint de prioriteiten voor de implementatie van de volgende stories.

✣  ✣  ✣

✣  ✣  ✣

Schrijf een story bij voorkeur op een A6 systeemkaart of een Wiki, zodat de hoeveelheid tekst noodzakelijkerwijs beperkt blijft—een story is een belofte tot communicatie geen volledige specificatie.

Essentieel is dat er glasheldere acceptatiecriteria zijn die alle discussie over al of niet accepteren van het opgeleverde resultaat uitsluiten. Een helder en eenvoudig af te vinken lijst van concreet meetbare criteria voorkomt veel narigheid en gedoe achteraf.

Een story functioneert als een markeerpunt—je hoeft het niet in je korte termijn geheugen te houden, maar zodra je de story ziet komt het meeste van wat besproken is weer terug—met gelukkig hebben we de foto's nog van de systeemkaarten ondersteun je dit principe. Je kan ook de systeemkaarten als verhalen aan de muur hangen als je met een zelfselecterend team in een vaste ruimte aan de ontwikkeling en realisatie werkt.

NOTA BENE— verhalen aan de muur werkt moeilijker met een gedistribueerd team dat (onregelmatig) in dezefde fysieke ruimte bijelkaar komt. Overweeg daarvoor een elektronisch systeem zoals een Wiki dat toegesneden is op het ontwikkelproces.

Stop de stories vervolgens in de werkvoorraad zodat de klant altijd zelf de prioriteit kan bepalen en de ontwikkelaar eenvoudig van de kop van de lijst het volgende verhaal op kan pakken.

Spreek een simpel protocol en contract af zoals de risicoloos resultaat en rendement en je krijgt een soepel en zelforganiserend geheel.

Tip: titels van stories werken het beste als ze vinkbaar zijn en bijvoorbeeld een krantenkop zijn van het uiteindelijke resultaat. "Wekelijkse database backup" is bijvoorbeeld beter dan "Backup maken".

Kenmerken van kwalitatief goede stories) zijn:

• Onafhankelijk
  • Voorkom afhankelijkheden met andere {p|stories}}.
  • Schrijf stories om een basis te vormen.
  • Combineer {p|stories}} waar mogelijk om op te leveren in een enkele sprint
• Onderhandelbaar
  • {p|stories}} zijn geen contract.
  • Te vroeg te veel detail geeft de indruk dat meer discussie over deze {p|story}} niet nodig is.
  • Niet elke story dient onderhandelbaar te zijn—er kunnen beperkingen zijn die dit onmogelijk maken.
• Waardevol
  • Elke story dient van waarde te zijn voor gebruikers, klanten en belanghebbenden.
• Inschatbaar
  • Een story dient voldoende detail te hebben om de complexiteit en implementatietijd goed in te kunnen schatten.
  • Moeilijk in te schatten stories levert problemen op voor het realisatieteam indien een story te groot is, indien onvoldoende informatie is verstrekt of indien er te weinig domeinkennis is.
• Juist afgemeten
  • Elke story dient klein genoeg te zijn om in een enkele sprint af te kunnen maken.
  • stories waaraan in de nabije toekomst gewerkt gaat worden dienen kleiner en meer gedetailleerd te zijn.
  • Grotere stories zijn acceptabeler naarmate ze verderweg in de planning zitten.
• Testbaar
  • glasheldere acceptatiecriteria dienen in de terminologie van de klant uitgedrukt te worden.
  • Tests dienen zoveel mogelijk geautomatiseerd te zijn.
  • Alle teamleden dienen glasheldere acceptatiecriteria te eisen.

Bron: http://www.infoq.com/resource/vcr/330/file/V1%20Agile%20Business%20Analyst%20White%20Paper.pdf