Effektstyrd Scrum

Vi gillar Scrum. Jättemycket! Scrum är det mest effektiva sätt vi känner till för att bygga digitala lösningar. Med transparens och återkoppling i processen som gör det möjligt att styra. Det blir alltså möjligt att styra mot de effekter man tänkt sig, att effektstyra.

För att kunna effektstyra behöver man så klart ha en tydlig bild av vilka effekter man tänker sig. Det beskrivs i en Effektkarta ®. Styrningen påverkas sedan främst av följande två faktorer:

• kostnaden för att ha fel
• tillgängliga medel

I utvecklingsprojekt där det redan finns en infrastruktur och gott om tillgängliga medel har man friheten att kunna prova sig fram. Bygga små förbättringar och testa om de tänkta effekterna uppstår. Enklast gör man testerna i målmiljö med en begränsad del av användarna.

Ett helt annat scenario är om kostnaden för att ha fel är hög och mängden tillgängliga medel är begränsad. Ofta handlar det om innovativ nyutveckling, där infrastrukturen ska skapas i projektet. Här är det också svårare att förstå användarnas behov, då det ofta är en ny tjänst vi tänker oss. I dessa fall blir det för riskabelt att prova sig fram och man måste hela tiden fokusera på att reducera risken för misstag.

Utvecklingsprojekt där kostnaden för att ha fel är hög och mängden tillgängliga medel är begränsade har vi många års erfarenhet av, och därför har vi tagit fram en komplettering till Scrum för det. Vi sätter fokus på hur beställarsidan ska arbeta för att följa grundprinciperna i Scrum, men minska risken för att bygga fel. Vår komplettering väljer beställarens perspektiv  och ger därför en helt annan bild av Scrum än den man brukar se.

Det här arbetssättet innebär att

• Beställarsidan kompletteras med en UX Lead
• Backloggen är resultatet av en validerad hypotes om användarnytta
• User Stories innehåller krav på nytta i form av design, regler och acceptanskriterier
• Backlog refinement används för att detaljera User Stories som ligger några sprintar fram med design och acceptanskriterier
• Definition of Done innefattar ett godkännande av användargränssnittets utformning (funktion, form och innehåll)
• Användningstester görs löpande vid sidan om teamets arbete
   

Beställarsidan kompletteras med en UX Lead

Product Owner är vanligen en person med linjeansvar och med erkänt god kunskap om verksamheten. Och hon har vanligen ett engagemang i verksamheten som fyller hennes dag. Scrum förutsätter att Product Owner ska finnas till hands hela tiden under sprintarna för att svara på detaljfrågor om designen. Och hon ska kunna omsätta sin bild av nytta till detaljerade egenskaper och acceptanskriterier i varje User Story.

Vår erfarenhet är att Product Owners varken har den tid eller de kunskaper som krävs för att kunna svara på teamets alla frågor. Lösningen är att tillsätta en UX Lead som blir Product Owners högra hand. Product Owner äger även fortsättningsvis alla frågor som handlar om verksamhetspåverkan. Oavsett om det gäller pengar, organisation eller vilka nyttor man tänker sig. Men Product Owner slipper dilemmat med att svara på frågor och besluta om regler, funktionalitet och utformning på detaljnivå.  

Rollen UX Lead tar ansvar för att:  

• Hjälpa verksamheten ta fram en Effektkarta baserad på analys i den omfattning man har tid till
• Ta fram konceptdesign och testa den
• Detaljera kravbilden till User Stories med visuell design, regler och acceptanskriterier
• Operativt hjälpa Product Owner att hålla ordning i Backlog
• Bistå teamet och svara på alla detaljfrågor i sprinten
• Stötta Product Owner i prioriterings- och avgränsningsbeslut
• Löpande validera att lösningen skapar förväntad nytta
   

Backloggen skapas som ett resultat av en validerad hypotes om användarnytta

Bakloggen ska innehålla User Stories. Innan man kommer dit behöver man ha en bild över vilken förändring som den tänkta lösningen ska bidra till och på vilket sätt; en Effektkarta. Ännu viktigare än Effektkartan är att ta fram hög-nivå design som testats i användning. Det man testar är minst att användare förstår uppbyggnaden och gillar den. I en mer komplex lösning bör man ha testat de viktigaste flödena med en prototyp och validerat eller troliggjort att den nytta man tänker sig kommer att uppstå. Man bör alltså validera att den hypotes man har om den nya tjänsten/produkten kan bevisas vara rimlig.  

Förutom det vackra i att ha en grov uppfattning om hur lösningen ska se ut, så skaffar man då också en grov uppfattning om hur den kan byggas, systemarkitekturen. En erfaren utvecklare och arkitekt ska se över lösningen så att den också är rimligt enkel att bygga och underhålla.

User stories innehåller krav på nytta i form av design, regler och acceptanskriterier

UX Lead ansvarar för att beskriva hur det som byggs ska kunna skapa värde i användning. Det betyder i klartext att UX Lead ska detaljera konceptdesignen för den specifika storyn och försöka detaljera de egenskaper man förväntar sig till Acceptanskriterier. Fokus för UX Leads arbete är inte nästa sprint, utan hon bör ligga längre fram. Vi använder mötet Backlog Refinement för att testa idéer som känns svåra och viktiga längre ner i backloggen.

Teamet kan då ge tips, ställa frågor eller - som ibland händer - helt såga den föreslagna utformningen. UX Lead och teamet går igenom designen, regler och acceptanskriterier. Senare, när en User Story ska spelas i planeringsmötet uppstår vanligen inga nya frågor. Teamet känner sig trygga i vad som ska byggas och planeringsmötet går snabbt.

Definition of Done (DoD) innefattar ett designgodkännande

Innan en User Story anses klar (Done) och redo att visas på demon, så ska den godkännas av UX Lead. Ibland upptäcks då smärre fel som kan rättas direkt. Fel label, dålig linjering av fält eller knappar eller bortglömda fält. Ibland finns lite allvarligare funktionsfel som kanske är resultatet av otydliga krav och som framför allt skulle ta för lång tid att rätta i sprinten. Om det då är ett avgränsat, mindre fel, kan UX Lead välja att godkänna ändå, men informera Product Owner om att det kommer att behövas kompletteringar i en eller flera User Stories. Om det är en stor avvikelse kommer UX Lead att rekommendera Product Owner att inte godkänna den. Den här kompletteringen av DoD ökar teamets träffsäkerhet på ett maximalt effektivt sätt, de stories som går upp till demon har inga onödiga småfel.

Användningstester kan göras löpande vid sidan om teamets arbete

UX Lead planerar för och genomför validering av produkten. Med validering menar vi att säkerställa att produkten skapar den förväntade nyttan för användare och verksamhet. Till sin hjälp har UX Lead Effektkartan som förklarar vilka nyttor produkten kan ge i en konkret användningssituation. Valideringen sker med användningstest och det kan vara både mindre tester av avgränsad funktionalitet med ett fåtal personer, eller ett större användningstest av en mer sammanhängande funktionalitet av lösningen. Teamet erbjuds att närvara om möjligt.  Resultatet av testet återförs som nya, kompletterande User Stories om ändringar eller tillägg behövs, eller bara som tummen upp till teamet.

 

Vill du lära dig mer om hur man gör? Anmäl dig till kursen Agil UX eller Lida eller leda agila projekt

Vill du veta mer? Kontakta någon av våra regionchefer om du vill ha hjälp i något projekt.