Tips för hantering av krav i Scrum

Vad är ett krav och hur bör det vara definierat?

Det är inte alltid att det är så att beställaren/produktägaren tar fram kraven inför en sprint. Framförallt inte när det gäller teknik. Produktägaren ska självklart vara högst delaktig i detta arbete men kan behöva hjälp.

Det viktigaste oavsett ven som skriver kraven är att den personen försöker se det ur beställarens synvinkel. Vad är det som är behovet? Det är väldigt vanligt att man börjar fokusera på lösning istället för att fokusera på behov och resultat.

Det är skillnad på:

”Vi har ett behov av att få ut rapporter från vårt ekonomisystem. En rapport som vi behöver är att se hur mycket som är fakturerat per månad per projekt”

”Vi har ett behov av att få ut rapporter från vårt ekonomisystem. En rapport som vi behöver är att se hur mycket som är fakturerat per månad per projekt . För detta måste vi öppna i brandväggen, göra en .NET sida och använda ekonomi APIet.”

Återigen, se kraven ur beställarens perspektiv. Om det finns krav på att det ska göras i .NET så absolut, men det kanske inte är ett krav att t.ex. öppna upp brandväggen utan det kanske visar sig att man måste göra det för att få det att fungera. Det är heller inte omöjligt att det visar sig att man inte behövde göra något i brandväggen eller att det löste sig på annat sätt.

Vi arbetar ofta med webbyråer som partners och de arbetar inte agilt och framförallt inte i gemensamma sprintar. Det betyder att de oftast levererar form eller även HTML/CSS innan en sprint. Kraven på utseendet är därför oftast väldigt tydliga och detaljerade. Det som behöver redas ut är oftast att förtydliga scenarier.

Krav är väldigt olika beroende beroende på hur projektet ser ut.

Dela upp krav i flera krav

Det man också bör tänka på är att dela upp sitt innehåll i kraven som gör att det går att prioritera mellan dem. Om man har en jättestort krav som innehåller väldigt mycket kan det vara läge att dela upp kravet i flera krav. På det sättet blir det möjligt att prioritera mellan eller välja bort vissa delar. Här är det bra att ha lite framförhållning för om man som beställare kommer på sent att vissa delar av ett krav ska falla bort så leder det ofta till ny planering då kravet ändrats och vissa uppgifter måste korrigeras.

Hur många krav bör man ha i en sprint?

Förutom att dela upp ett krav i flera för att underlätta prioritering i sprinten finns det så klart fler anledningar.

En anledning till att det inte bör vara för få krav i en sprint är att om man t.ex. har 3 krav i en sprint och det inte går som planerat. Sprinten har en hastighet på ca 60% mot uppskattningarna den uppskattade hastigheten. I det läget blir bara 1 av 3 krav leverade i sprinten. Detta eftersom tanken är att allt som levereras ska vara komplett för att kunna lanseras. Självklart kan man säkert sänka ambitionsnivån i krav nummer 2 för att få det ”klart”.

Det är heller inte bra att ha för många krav i en sprint då erfarenheten säger att det blir väldigt mycket testning som behöver utföras. Vi har som rutin att för varje krav ha ett acceptanstest när alla uppgifter är klara inom ett krav. Ju fler krav desto fler timmar till testning. Självklart behöver inte alla krav ha lika mycket testning men min erfarenhet säger att det gäller att hitta en balans mellan för få krav och för många.

Gå igenom kraven innan sprinten

Av erfarenhet har det visat sig att oavsett vem som skrivit kraven så behövs ett möte innan sprintplaneringen då kraven gås igenom med delar av teamet och produktägaren för att så tidigt som möjligt reda ut stora risker, utmaningar, förändra kraven något för att få ut så mycket värde som möjligt under sprinten.

Summering

Vi har följt denna process nu ett bra tag och sett att det är ett lyckat koncept. Förbereder man sig på detta sätt så minskar man risken för ineffektivet, tar beslut enklare under sprintens gång och resultatet blir bättre. Det är win-win för alla involverade.

Ola Wallin
2012-05-22