Lars Wiborg

Att skapa ansvarstagande beställare

2017-04-25 Artikelbanken Kravhantering Läst 746 gånger

Låt oss leka med tanken att din nästa sprint är en fotbollsmatch. IT och beställarsidan spelar tillsammans mot ett gemensamt mål. Motståndare är det gamla vanliga laget Tid, Pengar och Funktionalitet. Föreställ dig då att delar av laget dyker upp till matchen utan utrustning. En del har inte skor med sig, andra saknar byxor. Sista stunden i omklädningsrummet spenderas inte med pepp utan i fruktlösa diskussioner om vem som ska spela var och varför. 

I en del organisationer startar sprintarna ständigt med oförberedda beställare som tvingas använda den gemensamma sprintstarten till att försöka prata ihop sig. Stora organisationer lider ofta av regionala preferenser och begrepp. Dessa blir extra tydliga när de olika regionernas representanter möts på plats för att diskutera sina behov. På IT-sidan skapar det frustration över att behöva spendera tid på grundläggande verksamhetsdiskussioner som de ändå inte kan bidra till. Kraven blir dessutom ofta av låg kvalitet när tiden tryter framåt eftermiddagen och alla ska resa hem igen.

Tillbaka till fotbollsmatchen som pågår som bäst. Laget rycker fram mot motståndarmålet men plötsligt kommer nya direktiv. Inte bara från tränaren, utav från lite varstans i laget: ”Passa bakåt, nej framåt! Ut på flanken, nej in i mitten!”.

Problemet med oklara kommunikationsvägar är också vanligt. IT-sidan får olika direktiv från olika intressenter. User stories ändras och prioriteringar görs om. Gärna sent i sprinten och strax innan produktionssättning. I en fotbollsmatch får det spelet att stanna av. Under en sprint skapar det förvirrade utvecklare som inte vet vem de ska lyssna på.

I likhet med fotbollslag som tappat gnistan med oklara spelstrategier och disciplinära problem, har ofta 'stjärnorna' i laget, eller på beställarsidan, frikort från regelverket. Exempel på stjärnor är en flitig idéspruta på verksamhetssidan. Hon blir kompis med utvecklarna och får inofficiellt mandat att skjuta in uppdrag från sidan. Eller en dominant produktägare som inte alltid har tid att vara med på alla möten men tar igen det med sena ändringar på eget initiativ.

Under ett uppdrag som testledare tog jag fram en ny sprintprocess för att angripa problem likt de ovan. För att lyckas insåg jag att processen måste vara enkel och tydligt kommunicerad för att uppnå acceptans hos alla parter. Vidare måste den vara tillräckligt detaljerad för att alla skulle kunna veta vad som förväntades av dem, och därmed kunna följa den. Till sist ville jag fokusera på att förenkla kommunikationen och skapa arbetsro, för att minska förvirringen och stressen som brukade uppstå då releasen närmade sig.

Sprintprocess för ansvarstagande beställare

Den nya sprintprocessen delades in i fyra moment:

  • Business Preparation
  • IT Preparation
  • Development & Verification
  • Acceptance & Deploy

Business Preparation

Med ett eget moment för beställarsidans föreberedelser får de ett särskilt fokus. I ett Business Planning-möte träffas de för att arbeta fram den kommande sprintens innehåll. IT-sidan finns tillgänglig för att svara på frågor och underlätta tidsuppskattningar men i övrigt ligger fokus på verksamhetens diskussioner.

Som mall för produkten från detta möte används förkortningen DEEP.

  • Detailed – lagom detaljerade krav, 
    'Som [roll] behöver jag kunna [behov] så att jag kan [syfte]'
  • Emergent – syftar på krav sprungna ur tidigare krav i en dynamisk backlog
  • Estimated – grovt tidsuppskattade krav (S, M, L, XL)
  • Prioritized – prioriterade krav, gärna enl MoSCoW (1. Must, 2. Should, 3. Could, 4. Won't)


Utan att beställarna förberett sig och producerat ett antal user stories går inte sprintprocessen vidare. Beställarsidan får därmed ansvar för att lägga grunden för sprinten.

Business Preparation/IT Preparation

Nästa steg tas med Sprint Planning-mötet. Ett gemensamt möte som sker i gränslandet mellan Business Preparation och IT Preparation. Här diskuterar IT-sidan och beställarsidan lösningsförslag på de user stories som tagits fram, vilka därmed detaljeras ytterligare. I det fall ny funktionalitet kräver att dokumentation, utbildningsmaterial eller liknande uppdateras, skapas tasks för det.

Testarna är också med och definierar acceptanstestfall för resp user story, tillsammans med beställarsidan. Dessa testfall prioriteras också samt grupperas efter vilken funktionell del av systemet de testar. Alla testfall kommer att appliceras i den aktuella sprinten men i nästa sprint blir de en del av en ständigt växande testbas av regressionstestfall.

Varje user story får även en ägare på beställarsidan. Den personen blir user storyns särskilda kontaktyta mellan IT och beställarsidan. Inga frågor rörande user storyn får runda denna person och därmed skapas mer lugn och tydlighet för utvecklarna. På ett högre plan är systemägaren på beställarsidan på samma sätt ägare till sprinten och ansvarig för frågor rörande innehållet som helhet.

Bortsett från att vara ett möte för att detaljera beställarsidans user stories, blir sprintplaneringen ett unikt tillfälle då hela teamet från såväl IT som verksamheten möts. Med en gemensam sprintplanering och samsyn på sprintens innehåll ökar förutsättningarna för ett samarbete då alla arbetar mot samma mål och med samma fokus.

IT Preparation

Under mötet IT Planning detaljplanerar IT-sidan sprinten med beställarsidan tillgänglig för frågor och förtydliganden. Lösningsförslagen till beställarsidans user stories bryts ner i development tasks, tidsuppskattas på timnivå och schemaläggs, bl a med tanke på när ägaren på beställarsidan är tillgänglig och inte på resande fot t ex.

Testarna granskar acceptanstestfallen så de är testbara och diskuterar ytterligare utforskande tester i dialog med utvecklarna. Är det någon user story som inte framstår som genomförbar efter denna analys, får beställarsidan prioritera om, ändra omfattning eller lyfta ut denna ur sprinten.

När detta planeringsmoment är över har beställarsidans ursprungliga behovsbeskrivning detaljerats steg för steg. Behoven har prioriterats, lösningsförslag har tagits fram och tydliga acceptanstestfall har också skapats, liksom ytterligare checklistor och testidéer baserat på tips från utvecklarna. Därmed har alla förutsättningar för framgångsrik och smidig utveckling skapats.

Development & Verification

I detta iterativa moment där den mesta arbetstiden ligger, bygger utvecklarna lösningar till beställarsidans user stories. Efter en lösning är färdigutvecklad och implementerad i systemtestmiljön, systemtestas den. Buggar rapporteras och rättas, och när systemtestningen är klar övergår ärendet till acceptanstest av ägaren på beställarsidan.

Skulle beställarsidan vilja ändra något går det bra, men eftersom sprintens slutdatum är fast, kommer alla större ändringar leda till mindre tid för påföljande user stories. Samma sak gäller ifall beställarsidan inte är tillgänglig eller inte kan ge besked. Med en Time boxad sprint ges beställarsidan tydliga ramar, incitamenten för att bidra ökar, och risken för att user stories växer bortom kontroll minskar.

Efter att ägaren av user storyn förklarat sig vara nöjd stängs ärendet och utvecklingen fortgår med nästa user story.

Acceptance & Deploy

När sista user storyn  fått sin lösning accepterad går sprinten in i sitt slutgiltiga moment då systemet regressionstestas och sprintens innehåll sätts i produktion. Att skapa ett särskild moment för acceptans och leverans, är ytterligare ett sätt att bygga in mer lugn i sprintarbetet och blockera sena ändringar dagarna innan produktionssättning.

Efter regressionstesterna, som baseras på tidigare sprintars acceptanstestfall, hålls en Sprint Demo öppen för alla. Syftet med demon är såväl att sprida kunskap om vad som kommer att levereras, som att få en sista formell feedback från redan kontaktade intressenter innan prodsättning.

Baserat på resultatet från acceptans- och regressionstesterna samt med återkoppling från demon, genomförs ett formellt möte, Business Accept, mellan systemägaren på beställarsidan och förvaltningsansvarig på IT-sidan. Här ges tillfälle att formellt acceptera eller modifiera innehållet i sprinten. Därefter stänger systemägaren sprinten och dess innehåll kan levereras till produktionsmiljön.

Sammanfattning

Det övergripande målet för processens steg och moment är förstås att åstadkomma leveranser med hög kvalitet. Tidigare pressades IT-sidan ofta mellan sprintens slutdatum på ena sidan, och dåliga förutsättningar från beställarsidan på den andra. Dåliga krav ledde till många och sena ändringar, som i sin tur försenade regressionstesterna, vilket gav upphov till rättningar efter produktionssättning.

Genom att låta betällarsidans bidrag utgöra grundvillkoret för hela processen, flyttas initiativet och ansvaret från IT-sidan till beställarsidan. Time boxing av utvecklingsmomentet ser till att ansvaret stannar på beställarsidan, och acceptansen i sista momentet är kvittot på att IT-sidan motsvarat förväntningarna.

Fotbollslaget, som tidigare sprang på alla bollar samtidigt, kommer numera väl förberett till matcherna. Innan matchen pratar de igenom taktiken i lugn och ro, och anfallen läggs upp efter en väl genomarbetad strategi. Tillsammans rundar de Tid, gör tunnel på Pengar och skjuter sedan bollen rakt i krysset utan att Funktionalitet haft en chans att stoppa dem. Det är lagarbete när det är som bäst!

Dela artikeln