MoSCoW

MoSCoW metoden – Visualisera & tydliggör områden som ska prioriteras

Introduktion

Det gäller att använda de resurser som finns tillgängliga inom Region Halland på rätt sätt samt att lägga mest krut på det som är viktigast. Vi behöver fokusera på det som är viktigt och som leder till en nytta för hela Region Halland. Det finns ett mycket bra verktyg för att få hjälp med att strukturera upp våra prioriteringar. Detta verktyg kallas för MoSCoW-metoden och grundades av en engelsman vid namn Dai Clegg under början av 1990-talet.

Själva ordet MoSCoW är en akronym och står för följande begrepp:

• M – Must have (Måste ha)

• S – Should have (Borde ha)

• C – Could have (Kan ha)

• W – Wont have right now (Kan ha, men inte just nu)

Nedan följer förtydliganden av dessa och hur vi använder metoden för att sätta prioritering främst på våra Features, men den kan även nyttjas för prioritering av User Stories.

M – Must have (Måste ha)

"Must have"– punkter är de som anses vara obligatoriska Features för sprinten. Dessa måste finnas där för att Region Halland ska kunna röra sig framåt över huvud taget. Om man ställer sig frågan, ”Vad händer om X inte finns?” och svaret då är ”Då kommer vi inte vidare alls”, då har man hittat en punkt som är Must have. Men om det finns något sätt för att komma vidare utan denna X-punkt, då har man hittat en Should have– punkt eller Could have– punkt. Att kategorisera en Feature som en Should have– eller Could have–punkt betyder inte att den inte kan levereras, utan endast att dessa levereras inom sprinten efter det att samtliga Must-have har prioriterats.

En Must-have Feature/User Story skall ha Priority 1 i DevOps.

S – Should have (Borde ha)

“Should have”- punkter är de Features som borde ingå i sprinten om det är möjligt. Om sprinten har kapacitet och tid för detta och om det inte utmanar någon av de Must have- Features som finns, då borde dessa Features levereras eller ingå i prioriteringen inom det specifika området. Features som kategoriseras som Should have är:

1. Viktiga men inte avgörande.

1. Kan vara smärtsamma att lämna utanför, men lösningen är fortfarande genomförbar.

1. Kan komma att kräva någon form av tillfällig lösning eller omväg så som att förändra förväntningarna, lite ineffektivitet, pappersarbete och så vidare. Denna lösning är ofta bara temporär.

En Should-have Feature/User Story skall ha Priority 2 i DevOps.

C – Could have (Kan ha)

“Could have”– punkter är de Features som skulle kunna inkluderas så länge de inte påverkar några av Must have– eller Should have-. Detta är Features som hör till möjliga punkter att genomföra och dessa kommer endast att levereras i sin helhet i bästa möjliga scenario. Om ett problem uppstår som innebär att deadlinen är i fara, då är de en eller flera av dessa Features och punkter som man ska välja att först släppa taget om inom den existerande tidsramen. Could have- Features kan definieras som:

1. Önskvärda men mindre viktiga.

1. Mindre påverkan på helheten om de utelämnas i jämförelse med att utelämna en Should have-Feature.

En Could-have Feature/User Story skall ha Priority 3 i DevOps.

W – Won't have right now (Kan ha, men inte just nu)

“Won't have”– punkter är de Features som inte behöver bli implementerade just nu.

En Won't-have Feature/User Story skall ha Priority 4 i DevOps.