En af de tilbagevendende udfordringer jeg ser, når jeg supporterer agile projekter, er, at features ikke er tilstrækkeligt godt defineret, når man skal i gang med at bryde ned i stories og estimere dem – enten ved en PI planning eller i forbindelse med sprint refinement og sprint planning. Det gælder uanset om det er et SCRUM baseret projekt eller det er indenfor rammerne af SAFe®. Et par specifikke problemstillinger dukker som regel op:
- I de værste tilfælde er featuren beskrevet med få linjer tekst, der helt kort ridser op HVAD det er man ønsker at få lavet.
- Manglende fokus på hvilken problemstilling det er forretningen ønsker adresseret, hvad er det underliggende behov?
- Manglende konkretisering af featurebeskrivelsen, f.eks. gennem acceptkriterier.
- Manglende fokus på de non-funktionelle aspekter af featuren (performance, stabilitet, sikkerhed, brugervenlighed mv).
- Tilbageløb i forbindelse med test, løsningen dækker ikke forretningens behov.
Kunne man med få midler gøre disse features bedre? Kunne man skabe et bedre grundlag at arbejde ud fra uden at skulle tilbage til de gamle kravspecifikationer, som vi kender fra tidligere? Og ikke mindst kunne man skabe et fælles billede for teamet at arbejde videre med? Det vil jeg påstå man kan, ved at starte med noget helt simpelt som f.eks. denne top 3:
- Skab et fælles billede af HVORFOR featuren overhovedet skal laves. Dokumenter problemstillingen i skal forsøge at afhjælpe, sæt ord på hvilken værdi det er forretningen skal have ud af featuren
- Visualiser problemstillingen og den ønskede løsning i stedet for mange sider dokumentation. F.eks. gennem procesmodellering, storyboards, personas etc. Den Agile forretningsanalytiker har masser af gode værktøjer i sin værktøjskasse.
- Bliv enige om hvad der skal til for at acceptere en feature. Med andre ord definer acceptkriterier for featuren.
Add 1.
Start med at se (eller gense) Simon Sineks TED talk:”Start with WHY”. Dokumenter jeres HVORFOR i form af en Fordels hypotese – definer en hypotese om hvad det er forretningen forventer at få ud af featuren? Hvilken værdi vil den give forretningen, når den kommer i drift som den ikke har i dag? Ved at fastholde forretningens og Product Owner’s fokus på dette, bliver der plads til at teamet kan bruge de stærke kompetencer de har i at finde den rigtige løsning på problemet – så fokuserer vi alle på det vi er stærkest til. Og husk; at få featuren ”ready” er ikke udelukkende forretningens opgave, det bør være et tæt samarbejde mellem forretning og team.
Add 2.
Der findes mange forskellige måder at identificere og visualisere såvel problemstillinger som løsninger på, personligt har jeg en stor forkærlighed for procesmodellering – dette skyldes nok at jeg efterfølgende har stor værdi af denne, når jeg skal designe min test ? Det kunne også være brainstorming workshops, Personas, flowdiagrammer, use cases, story-mapping – der er meget at vælge imellem. Hjælp din forretning og dit team med at blive klædt bedre på.
Add 3.
Acceptkriterierne skal være en liste af ting, vi skal verificere for at sikre at forretningens behov er opfyldt… det er tilsyneladende rigtig svært at skrive, de mangler i hvert fald tit ? men måske var det nemmere hvis vi i stedet for skrev ”Definer accepttests fra starten af!”. For mange kan det være svært at få vendt begrebet acceptkriterier og få dem defineret godt, men hvis jeg i stedet for siger til en repræsentant fra forretningen: hvad har du tænkt dig at teste når den her feature kommer til test? Så har de sjældent svært ved at liste en række ting de vil afprøve, både solskinscenarier for at verificere at systemet kan understøtte de processer de har brug for, og kke mindst negative scenarier hvor de tænker, ”den her specialsituation skal den simpelthen kunne håndtere også”. Hvis du kan få det mindset ind fra starten af, så får du to ting:
- Direkte input til din accepttest.
- Dybere indsigt i hvad featuren skal kunne – mest på grund af de negative scenarier.