Innenfor programvareutvikling må vi hele tiden prioritere forskjellige oppgaver. Det kan være ny brukervendt funksjonalitet, feilretting, rydding av teknisk gjeld og "quality of life" for utviklerteamet.
ICE - Impact, Confidence and Ease - er en av de enklere modellene som vi kan utnytte til å hjelpe oss å prioritere. Den gir en rask pekepinne på hvilke verdi forskjellige oppgaver har.
Måten ICE fungerer er at vi gir en score fra 0 til 10 på tre områder:
Impact (Effekt): Hvor stor effekt vil oppgaven ha på løsningen? Det kan blant annet være målt i verdi for sluttkunder, verdi for bedriften eller verdi for prosjektteamet.
Confidence (Sikkerhet): Hvor sikre er vi på at oppgaven faktisk gir ønsket effekt? Har det en direkte målbar verdi, som for eksempel å spare penger? Har vi et datagrunnlag for å kunne si noe om effekten? Eller baserer vi oss på antagelser?
Ease (Enkelthet): Hvor enkelt er det å gjennomføre oppgaven? Jo mindre tid, ressurser, kostnad og teknisk kompleksitet, jo høyere enkelhetsscore bør en oppgave få.
Til slutt regner vi sammen scoren ved multiplikasjon: I*C*E.
Følgende er et enkelt eksempel på å prioritere to oppgaver.
Funksjon 1: Legge inn støtte for Vipps Login ved innmelding av nye brukere
Effekt: 8 - I dag har vi problemer med at nye potensielle brukere faller av i innmeldingsflyten. Ved å implementere Vipps Login vil flyten bli enklere og vi vil ha større retention på nye brukere.
Sikkerhet: 8 - Erfaring fra andre bedrifter viser at det er enklere å få brukere til å melde seg inn i digitale tjenester ved bruk av Vipps.
Ease: 4 - Krever en del utvikling rundt innlogging for å støtte tredjeparts OIDC løsninger.
Funksjon 2: Optimalisere cache ved å gå over til Redis
Effekt: 5 - Dagens løsning sliter med treg cache og det har tidvis påvirkning på brukeropplevelsen.
Sikkerhet: 2 - Det er usikkert om å gå over til Redis faktisk fikser problemet. Det sees på som høyt sannsynlig at problemet ikke ligger rundt valg av cache løsning.
Ease: 8 - All caching i systemet kan enkelt byttes ut med Redis ved å installere en pakke og bytte ut to kodelinjer i oppstartsprogrammet.
Her får Funksjon 1 en score på 256 mens Funksjon 2 får en score på 80. Med ICE scoren som en pekepinne kan vi nå enklere prioritere funksjonene inn i sprinter.
Det finnes mange andre prioriteringsmetoder. Det viktigste er å kunne finne en metodikk som fungerer for prosjektet og som faktisk blir brukt. En av ulempene med ICE er at det kan bli for enkelt og ignorerer for mange faktorer.
Itamar Gilad har skrevet en interessant artikkel som gjør et dypere dukk i ICE og ser på andre måter å regne ut ICE scoren.
https://itamargilad.com/the-tool-that-will-help-you-choose-better-product-ideas