Hvor ofte bør vi prioritere om?

Annenhver uke holder for de fleste team. Oftere gjør det vanskelig å bli ferdig med noe, og sjeldnere rekker virkeligheten å endre seg mellom gangene.

Hva gjør vi med alt som aldri blir bygget?

Slett det. En backlogg med 300 poster er en liste ingen leser. Det som virkelig betyr noe, kommer tilbake av seg selv, som regel innen noen uker og med et bedre argument.

Hvem bør eie prioriteringen?

Én person, som lytter bredt og bestemmer alene. Prioritering i gruppe gir lister der alt er nest viktigst, og da avgjøres rekkefølgen av hvem som orker å argumentere lengst.

Hvordan håndterer vi en stor kunde som krever en funksjon?

Skriv ned hva kunden prøver å oppnå, hvor mange andre som har samme problem og hva bygget koster. Ofte finnes en mindre løsning som dekker begge, og den blir synlig først når behovet er formulert.

Trenger vi estimater i timer?

Sjelden. En grov størrelse i dager, uker eller måneder holder for å velge mellom to forslag. Presise estimater koster tid å lage og bommer likevel på det som er usikkert.

Når er et veikart verdt å ha?

Når det beskriver problemer i tidsrekkefølge. En liste over funksjoner med datoer blir et løfte dere må forklare bort; en liste over problemer tåler at virkeligheten endrer seg.

Å bestemme hva som skal bygges som det neste

Torn StudioPublisert 2026-08-273 min lesetid

Torn Studio er et AI-byrå som bygger nettsteder, digitale produkter og innhold. Utradisjonelt.

Kort svar

En prioriteringsbeslutning holder når den skrives ned: hva som bygges, hvilket problem det løser, hva som velges bort, og hva som skal være sant om to måneder for at beslutningen skal ha vært riktig. Én side per beslutning holder, og den leses høyt på neste statusmøte.

De fleste backlogger er lister over alt noen noen gang har bedt om. En slik liste kan sorteres i det uendelige, fordi den mangler det som gjør sortering meningsfull: hva dere prøver å oppnå dette kvartalet.

Start med hva som skal være sant om tre måneder

Et mål formulert som en tilstand gjør prioriteringen enkel. Hvert forslag kan holdes opp mot "en ny kunde kommer i gang på egen hånd", og de fleste faller bort på ti sekunder. Et mål formulert som en aktivitet gjør ikke den jobben, fordi aktiviteter alltid lar seg begrunne.

Tre spørsmål som skiller forslagene

Still dem i rekkefølge; det tredje gjør mest arbeid. Et forslag som koster null å utsette, kan utsettes, uansett hvor høylytt det etterspørres.

Hvilket problem løser det, for hvem, og hvor ofte oppstår det?
Hva blir vi sikrere på når det er bygget?
Hva koster det å utsette i tre måneder?

Skriv beslutningen på én side

En beslutning som bare ble sagt i et møte, reforhandles neste gang noen blir irritert. Én side med dato, valget, alternativene som lå på bordet og hva som skal være sant om to måneder, gjør at neste diskusjon starter der den forrige sluttet. Prinsippet er det samme som en arkitekturbeslutning i et repo: begrunnelsen overlever den som skrev den.

Gjør om prioriteringen annenhver uke

To uker er tett nok til å fange opp en endring og romslig nok til å bli ferdig med noe. Målet gjennomgås hvert kvartal. En beslutning som viser seg å være feil etter fire uker, er billig å endre så lenge det står skrevet hvorfor den ble tatt.

Hva som pleier å gå galt

Listen blir en ønskeliste, den største kunden får siste ord, og alt som er vanskelig å anslå, utsettes til det haster. Vår erfaring er at alle tre er symptomer på det samme: et mål ingen i teamet kan sitere utenat.

Vanlige spørsmål

Hvor ofte bør vi prioritere om?: Annenhver uke holder for de fleste team. Oftere gjør det vanskelig å bli ferdig med noe, og sjeldnere rekker virkeligheten å endre seg mellom gangene.
Hva gjør vi med alt som aldri blir bygget?: Slett det. En backlogg med 300 poster er en liste ingen leser. Det som virkelig betyr noe, kommer tilbake av seg selv, som regel innen noen uker og med et bedre argument.
Hvem bør eie prioriteringen?: Én person, som lytter bredt og bestemmer alene. Prioritering i gruppe gir lister der alt er nest viktigst, og da avgjøres rekkefølgen av hvem som orker å argumentere lengst.
Hvordan håndterer vi en stor kunde som krever en funksjon?: Skriv ned hva kunden prøver å oppnå, hvor mange andre som har samme problem og hva bygget koster. Ofte finnes en mindre løsning som dekker begge, og den blir synlig først når behovet er formulert.
Trenger vi estimater i timer?: Sjelden. En grov størrelse i dager, uker eller måneder holder for å velge mellom to forslag. Presise estimater koster tid å lage og bommer likevel på det som er usikkert.
Når er et veikart verdt å ha?: Når det beskriver problemer i tidsrekkefølge. En liste over funksjoner med datoer blir et løfte dere må forklare bort; en liste over problemer tåler at virkeligheten endrer seg.

Neste steg

Les videre

Gå dypere

Jobb med oss