ktg-plugin-marketplace/plugins/okr/skills/okr-offentlig-sektor/references/okr-integrations.md

OKR-integrasjoner: Agile, Prosjektportefølje og Verktøy

Hvordan OKR fungerer sammen med andre rammeverk og verktøy i offentlig sektor.

Innhold

1. OKR + Scrum
2. OKR + Kanban
3. OKR + Prosjektportefølje
4. OKR + SAFe
5. Verktøyintegrasjon

---

OKR + Scrum

Hvorfor kombinere?

OKR og Scrum utfyller hverandre:

OKR	Scrum
Hvorfor – Strategisk retning	Hvordan – Operasjonell utførelse
Kvartalsvis syklus	2-ukers sprinter
Outcome-fokus (resultater)	Output-fokus (leveranser)
Definerer suksess	Strukturerer arbeidet

Nøkkelinnsikt: OKR alene gir ikke struktur for daglig arbeid. Scrum alene gir ikke strategisk retning. Sammen skaper de en komplett arbeidsmodell.

Timing og synkronisering

OKR-syklus (4 måneder i DDT)
├── Sprint 1 (2 uker)
├── Sprint 2 (2 uker)
├── Sprint 3 (2 uker)
├── Sprint 4 (2 uker)
├── Sprint 5 (2 uker)
├── Sprint 6 (2 uker)
├── Sprint 7 (2 uker)
└── Sprint 8 (2 uker) + OKR review/retro

Praktisk tidslinje:

Tidspunkt	Aktivitet
2-4 uker før syklus	OKR-planlegging på organisasjons-/avdelingsnivå
1 uke før syklus	Team-OKR ferdigstilles
Syklusstart	Første sprint planning kobles til OKR
Midtveis (uke 8-9)	Mid-cycle OKR review
Syklusslutt	OKR scoring + retrospektiv

Sprint Goals som støtter Key Results

Sprint goals bør eksplisitt kobles til Key Results:

Eksempel:

Quarterly OKR:
Objective: Redusere saksbehandlingstid for tjenestefornyelse
  KR1: Redusere gjennomsnittlig behandlingstid fra 10 til 5 dager
  KR2: 95% av saker ferdigbehandlet innen SLA
  KR3: Redusere manuell håndtering fra 60% til 20%

Sprint 1 Goal:
"Implementere automatisk dokumentvalidering for å redusere manuell håndtering"
→ Støtter KR3

Sprint 2 Goal:
"Lansere selvbetjeningsportal for statussjekk for å redusere henvendelser"
→ Støtter KR1 og KR2

Sprint 3 Goal:
"Integrere med Folkeregisteret for automatisk datahenting"
→ Støtter KR1 og KR3

OKR i Scrum-seremonier

Sprint Planning

• Vis team-OKR før backlog-prioritering
• Still spørsmålet: "Hvilke backlog-items vil best drive våre Key Results?"
• Definer sprint goal som eksplisitt støtter et eller flere KR

Daily Standup

Legg til OKR-perspektiv:

• Standard: "Hva gjorde jeg i går? Hva gjør jeg i dag? Blokkere?"
• Med OKR: "Hvordan påvirker dagens arbeid våre Key Results?"

Sprint Review

• Vis ikke bare hva som ble levert, men hvordan det påvirker KR-progress
• "Vi lanserte feature X → dette har redusert behandlingstid med 1.5 dager → vi er nå på 7.5 dager (target: 5)"

Sprint Retrospective

Legg til OKR-refleksjon:

• "Flytter arbeidet vårt oss mot Key Results?"
• "Er sprint goals godt nok koblet til OKR?"
• "Bør vi justere OKR basert på læring?"

Praktisk eksempel: Komplett 4-måneders syklus

Kontekst: Vegtrafikksentralen skal forbedre informasjon til trafikanter

SYKLUS Q1 (Januar-April)

Uke -2 til 0 (Desember):
├── Avdelingsmøte: Definerer OKR basert på etats-OKR
├── Team-workshop: Bryter ned til team-OKR
└── OKR publiseres i Oboard

Team-OKR:
Objective: Gi trafikanter raskere og mer presis informasjon
  KR1: Redusere tid fra hendelse til varsling fra 15 til 5 min
  KR2: Øke nøyaktighet på estimert forsinkelse til 90%
  KR3: 80% av trafikanter vurderer informasjon som "nyttig"

Sprint 1-2 (Januar):
├── Sprint 1 Goal: "Implementere sanntidsintegrasjon med kameradata"
│   → Støtter KR1
├── Sprint 2 Goal: "Utvikle ML-modell for forsinkelsesestimering"
│   → Støtter KR2
└── Check-in: KR1 på 0.3, KR2 på 0.2, KR3 baseline etablert

Sprint 3-4 (Februar):
├── Sprint 3 Goal: "Lansere automatisk varslingsrute til radio/app"
│   → Støtter KR1
├── Sprint 4 Goal: "Teste og kalibrere forsinkelsesmodell"
│   → Støtter KR2
└── Check-in: KR1 på 0.6, KR2 på 0.5, KR3 på 0.4

Mid-cycle review (Uke 9):
├── Progress: KR1 god, KR2 på sporet, KR3 trenger fokus
├── Beslutning: Prioriter brukerundersøkelse i neste sprint
└── Ingen OKR-justering nødvendig

Sprint 5-6 (Mars):
├── Sprint 5 Goal: "Implementere push-varsler med forbedret UX"
│   → Støtter KR3
├── Sprint 6 Goal: "Gjennomføre brukertest og iterere"
│   → Støtter KR3
└── Check-in: KR1 på 0.8, KR2 på 0.7, KR3 på 0.6

Sprint 7-8 (April):
├── Sprint 7 Goal: "Optimalisere varslingspipeline end-to-end"
│   → Støtter KR1 og KR2
├── Sprint 8 Goal: "Stabilisering og dokumentasjon"
└── Sluttscoring: KR1: 0.9, KR2: 0.8, KR3: 0.75

OKR Retrospektiv:
├── Hva fungerte: Sprint goals koblet til KR ga fokus
├── Forbedring: Start brukerundersøkelse tidligere
└── Læring til neste syklus dokumentert

---

OKR + Kanban

Når Kanban passer bedre enn Scrum

Kanban egner seg for:

• Driftsteam med kontinuerlig arbeid (support, vedlikehold)
• Team som håndterer uforutsigbar innkommende mengde
• Arbeid som ikke passer i faste tidsrammer

Flowmetriker som Key Results

Kanban-metriker kan bli kraftige Key Results:

Metrikk	Beskrivelse	KR-eksempel
Lead time	Total tid fra forespørsel til levert	"Redusere lead time for byggesøknader fra 45 til 25 dager"
Cycle time	Aktiv arbeidstid (ekskl. venting)	"Redusere cycle time for klagesaker fra 8 til 4 dager"
Throughput	Antall saker ferdigstilt per periode	"Øke throughput til 200 saker/måned"
WIP	Arbeid under utførelse	"Maksimalt 5 parallelle saker per saksbehandler"

Eksempel OKR med flowmetriker:

Objective: Levere raskere og mer forutsigbar saksbehandling

  KR1: Redusere lead time for standard søknader fra 30 til 15 dager
  KR2: Oppnå 85% av saker ferdigbehandlet innen 20 dager
  KR3: Redusere cycle time variasjon (standardavvik fra 10 til 5 dager)

WIP-grenser og OKR-fokus

WIP-grenser (Work In Progress) tvinger fokus:

Kanban-tavle med OKR-swimlanes:

┌─────────────────────────────────────────────────────────┐
│ OKR: Raskere saksbehandling (WIP: 8)                    │
├────────────┬────────────┬────────────┬────────────────┤
│ Kø (∞)     │ Analyse(3) │ Beslut.(3) │ Ferdig         │
├────────────┼────────────┼────────────┼────────────────┤
│ ████       │ ██         │ █          │ ██████████     │
│ ████       │ █          │ ██         │                │
│ ██         │            │            │                │
└────────────┴────────────┴────────────┴────────────────┘

┌─────────────────────────────────────────────────────────┐
│ Operasjonelt/vedlikehold (WIP: 4)                       │
├────────────┬────────────┬────────────┬────────────────┤
│ Kø (∞)     │ Pågår (2)  │ Review (2) │ Ferdig         │
├────────────┼────────────┼────────────┼────────────────┤
│ ██         │ █          │ █          │ ████           │
└────────────┴────────────┴────────────┴────────────────┘

Poeng: OKR-arbeid får dedikert kapasitet gjennom egen swimlane med egen WIP-grense.

Kanban-kadenser for OKR-oppfølging

Kadense	Frekvens	OKR-relevans
Replenishment	Ukentlig	Prioriter arbeid som driver KR
Daily standup	Daglig	Sjekk flow mot OKR-mål
Delivery review	Annenhver uke	Vis KR-progress til stakeholders
Service review	Månedlig	Er vi på sporet til å nå KR?
Strategy review	Kvartalsvis	OKR retrospektiv

Kontinuerlig flow vs. syklusbasert OKR

Utfordring: Kanban er kontinuerlig, OKR er syklusbasert.

Løsning: Behold kvartalsvise OKR, men la arbeidet flyte kontinuerlig:

1. Sett OKR ved syklusstart – definerer retning
2. Replenishment-møter – prioriter alltid arbeid som støtter KR
3. Mid-cycle review – juster kapasitetsallokering om nødvendig
4. Syklusslutt – scorer OKR, men ingen "sprint-slutt" for arbeid

---

OKR + Prosjektportefølje

Tre typer OKR

Type	Fokus	Typisk eier	Tidshorisont
Prosjekt-OKR	Business outcome fra spesifikt prosjekt	Prosjektleder	Prosjektets varighet
Produkt-OKR	Langsiktig produktverdi	Produkteier	Kvartalsvis/årlig
Team-OKR	Teamets bidrag til felles mål	Teamleder	Kvartalsvis

Eksempel på forskjellen:

PROSJEKT-OKR (nytt saksbehandlingssystem):
Objective: Modernisere saksbehandling med nytt system
  KR1: 100% av saker håndteres i nytt system innen juni
  KR2: Redusere opplæringstid for nye saksbehandlere med 50%
  KR3: Oppnå brukertilfredshet (NPS) på +40

PRODUKT-OKR (saksbehandlingssystemet som produkt):
Objective: Bli det foretrukne saksbehandlingsverktøyet
  KR1: 90% av brukere logger inn daglig
  KR2: Redusere support-henvendelser med 30%
  KR3: 3 nye etater tar i bruk systemet

TEAM-OKR (utviklingsteamet):
Objective: Levere høy kvalitet med god hastighet
  KR1: Redusere produksjonsfeil med 40%
  KR2: Øke deployment-frekvens til 2x per uke
  KR3: Teknisk gjeld under 15% av backlog

Porteføljeprioritering basert på OKR

Bruk OKR-alignment som prioriteringskriterium:

Prioriteringsmatrise:

Prosjekt	Strategisk OKR-alignment	Business value	Kostnad	Prioritet
Prosjekt A	Høy (støtter 2 KR)	Høy	Medium	1
Prosjekt B	Medium (støtter 1 KR)	Høy	Lav	2
Prosjekt C	Høy (støtter 2 KR)	Medium	Høy	3
Prosjekt D	Lav	Medium	Lav	4

Praktisk prosess:

1. Definer portefølje-OKR – Hva skal porteføljen oppnå?
2. Koble prosjekter til OKR – Hvilke KR støtter hvert prosjekt?
3. Vekt etter impact – Hvor mye bidrar prosjektet til KR?
4. Prioriter ressurser – Alloker til høyest OKR-impact først

Store prosjekter over flere sykluser

Prosjekter som varer 12-36 måneder krever spesiell håndtering:

Fasebasert tilnærming:

PROSJEKT: Ny nasjonal vegdatabase (18 måneder)

Årlig strategisk OKR:
Objective: Etablere nasjonal vegdatabase som autoritativ kilde

Syklus 1 (Jan-Apr):
Objective: Etablere dataarkitektur og governance
  KR1: Datamodell godkjent av alle interessenter
  KR2: Governance-struktur implementert
  KR3: 3 pilotbrukere integrert

Syklus 2 (Mai-Aug):
Objective: Migrere data fra eksisterende systemer
  KR1: 80% av vegdata migrert og validert
  KR2: Datakvalitet på 95% for migrerte data
  KR3: Nedetid under 4 timer totalt

Syklus 3 (Sep-Des):
Objective: Skalere til nasjonal bruk
  KR1: Alle 11 regioner koblet på
  KR2: Responstid under 200ms for 95% av spørringer
  KR3: 500 aktive brukere

[Fortsetter inn i neste år...]

Nøkkelprinsipper:

• Årlig OKR gir strategisk stabilitet
• Syklus-OKR gir taktisk fleksibilitet
• Hver syklus har målbare outcomes, ikke bare milepæler
• Mid-cycle reviews vurderer om neste syklus-OKR er riktig

Milepæler vs. Key Results

Milepæl	Key Result
"Lansere system i juni"	"80% av brukere aktivt bruker systemet innen august"
"Fullføre integrasjon"	"Integrasjonen reduserer manuelt arbeid med 60%"
"Levere rapport"	"Rapporten fører til 3 konkrete beslutninger"

Regel: Milepæler beskriver hva vi gjør. Key Results beskriver hvilken effekt det har.

Når bruke milepæler som KR?

Unntaksvis OK når:

• Capability ikke eksisterer ennå (kan ikke måle effekt)
• Veldig tidlig fase av transformasjon
• Compliance-krav krever spesifikk leveranse

Men: Følg opp med outcome-basert KR i neste syklus.

---

OKR + SAFe (Skalert agile)

PI Objectives vs. OKR

Aspekt	OKR	PI Objectives
Når settes de	Før PI Planning	Under PI Planning
Hvem setter	Ledelse + team	Team under planlegging
Fokus	Strategisk outcome	Leveranse i PI
Tidshorisont	Kvartal/år	8-12 uker (PI)
Fleksibilitet	Kan justeres	Commitment

Nøkkelinnsikt: OKR er input til PI Planning. PI Objectives er output.

Hvordan kombinere

PROSESSFLYT:

1. Organisasjons-OKR defineres (4-6 uker før PI)
   ↓
2. Program-OKR avledes (2-3 uker før PI)
   ↓
3. PI Planning gjennomføres
   ├── Business context presenteres (inkl. OKR)
   ├── Team planlegger sprinter
   └── PI Objectives formuleres (støtter OKR)
   ↓
4. PI gjennomføres
   ├── Sprint goals støtter PI Objectives
   └── PI Objectives driver OKR-progress
   ↓
5. Inspect & Adapt
   ├── PI Objectives evalueres
   └── OKR-progress vurderes

Praktisk eksempel

Kontekst: Storprosjekt med 5 team (ART) i Direktoratet for digital tjenesteutvikling

ORGANISASJONS-OKR (Årlig):
Objective: Øke trafikksikkerhet gjennom bedre varsling
  KR1: 50% reduksjon i sekundærhendelser
  KR2: 90% av trafikanter varslet innen 5 min

PROGRAM-OKR (Kvartalsvis):
Objective: Lansere integrert varslingssystem v1.0
  KR1: System i produksjon med 99.5% uptime
  KR2: Integrasjon med 5 trafikksentre
  KR3: Positiv feedback fra 80% av operatører

PI PLANNING (PI 4):

Team Alpha (Backend):
PI Objective 1: "Levere API for sanntids trafikkhendelser"
PI Objective 2: "Implementere failover for kritiske tjenester"

Team Beta (Frontend):
PI Objective 1: "Lansere operatør-dashboard v1"
PI Objective 2: "Implementere varslings-workflow"

Team Gamma (Integrasjon):
PI Objective 1: "Koble 3 trafikksentre til plattform"
PI Objective 2: "Etablere datasynk med eksisterende systemer"

ALIGNMENT-SJEKK:
✓ Alle PI Objectives bidrar til Program-OKR
✓ Program-OKR støtter Organisasjons-OKR
✓ Avhengigheter mellom team identifisert

Når bruke OKR vs. PI Objectives

Situasjon	Bruk
Definere strategisk retning	OKR
Planlegge konkret leveranse	PI Objectives
Måle business outcome	OKR (Key Results)
Måle team commitment	PI Objectives
Kommunisere til ledelse	OKR
Koordinere mellom team	PI Objectives

---

Verktøyintegrasjon

OKR i Jira

Alternativ 1: Native Jira-struktur

Bruk Jira's eksisterende hierarki:

• Epic = Objective
• Story/Task = Arbeid som støtter KR
• Labels = Koble til spesifikk KR (f.eks. "KR1-saksbehandling")

Epic: "Raskere saksbehandling" (Objective)
├── Story: "Automatisere dokumentvalidering" [KR1]
├── Story: "Implementere selvbetjening" [KR1, KR2]
├── Story: "Integrere med Folkeregisteret" [KR3]
└── Story: "Forbedre søkefunksjon" [KR2]

Alternativ 2: OKR Board for Jira (anbefalt for større team)

Plugin fra Oboard som gir:

• Dedikert OKR-visning
• Automatisk progress-beregning fra issues
• Vekting av issues mot KR
• Dashboard og rapporter
• Confluence-integrasjon

Oppsett:

1. Installer OKR Board fra Atlassian Marketplace
2. Definer OKR-intervaller (matcher våre sykluser)
3. Sett opp organisasjonsstruktur (etater → avdelinger → team)
4. Lag OKR og koble til Jira issues
5. Progress oppdateres automatisk når issues lukkes

OKR i Azure DevOps

Alternativ 1: Native work item hierarki

Epic: "Objective: Forbedre digital selvbetjening"
├── Feature: "KR1: Øke selvbetjeningsgrad til 70%"
│   ├── User Story: "Som bruker vil jeg..."
│   └── User Story: "Som bruker vil jeg..."
├── Feature: "KR2: Redusere henvendelser med 40%"
│   └── User Story: "..."
└── Feature: "KR3: NPS over 50"
    └── User Story: "..."

Alternativ 2: Microsoft Viva Goals (AVVIKLET)

Merk: Microsoft annonserte i september 2024 at Viva Goals avvikles. Produktet ble fullstendig faset ut i 2025. Opprinnelig Ally.io (kjøpt av Microsoft i 2021), ble det til Viva Goals, og er nå nedlagt.

For organisasjoner som brukte Viva Goals:

• Oboard — norskutviklet, Microsoft 365-integrasjon, GDPR-compliant EU-hosting
• Quantive Results (tidl. Gtmhub) — enterprise OKR med AI-features
• Perdoo — god balanse funksjon/pris for mellomstore organisasjoner

Se seksjon "Andre OKR-plattformer" i okr-sources.md for full oversikt.

Oboard + Jira-integrasjon

For organisasjoner som bruker både Jira og ikke-Jira team:

┌─────────────────────────────────────────────────┐
│              Oboard OKR App                      │
│         (Sentralt OKR-dashboard)                │
├─────────────────────────────────────────────────┤
│                                                  │
│   ┌─────────┐    ┌─────────┐    ┌─────────┐    │
│   │  Jira   │    │ Azure   │    │ Annet   │    │
│   │ (Dev)   │    │ DevOps  │    │ (via    │    │
│   │         │    │ (Ops)   │    │  API)   │    │
│   └────┬────┘    └────┬────┘    └────┬────┘    │
│        │              │              │          │
│        └──────────────┼──────────────┘          │
│                       ↓                         │
│           Automatisk progress-sync              │
└─────────────────────────────────────────────────┘

Bruksscenario:

• Utviklingsteam bruker Jira → Progress synkes til Oboard
• Driftsteam bruker Azure DevOps → Progress synkes til Oboard
• Ledelse ser samlet OKR-progress i Oboard

Automatisk KR-oppdatering: Best practices

Hva kan automatiseres:

• Issue/work item completion → KR progress
• Story points ferdig → Prosentvis fremgang
• Query-resultater → Metrikk-KR (f.eks. antall bugs)

Hva bør IKKE automatiseres fullt ut:

• Kvalitative vurderinger
• Customer satisfaction (krever faktiske målinger)
• Business outcomes (lag = effekten kommer senere)

Anbefalt modell:

KR-type                  | Automatisering
-------------------------|------------------
Leveranse-KR             | Automatisk fra issues
Aktivitets-KR            | Automatisk fra issues
Metrikk-KR (intern)      | Semi-automatisk (dashboard)
Metrikk-KR (ekstern)     | Manuell oppdatering
Outcome-KR               | Manuell med kilde

Oppsett-sjekkliste

For Jira-basert OKR:

• Bestem struktur: Native epics eller OKR Board plugin?
• Lag konsistent labeling-konvensjon (f.eks. "S1-KR1")
• Sett opp Confluence-side for OKR-oversikt
• Definer workflow for OKR-oppdatering (hvem, når)
• Integrer med Sprint Planning-prosess

For Azure DevOps-basert OKR:

• Vurder Oboard vs. native work items
• Sett opp shared queries for KR-tracking
• Lag dashboard-widgets for OKR-visibility
• Koble til Power BI for avansert rapportering

For multi-tool organisasjoner:

• Vurder sentralt OKR-verktøy (Oboard, Quantive, Perdoo, e.l.)
• Definer integrasjoner per team/verktøy
• Etabler felles oppdaterings-kadense
• Lag "single source of truth" for ledelsesrapportering

---

Ressurser

Kilder brukt i dette dokumentet

• OKR Institute: OKR and Scrum Integration
• Scrum.org: How OKRs and Scrum Work Together
• Mooncamp: OKR and Agile
• Martin Fowler: Team OKRs
• Atlassian: OKR in Jira and Confluence
• Microsoft Learn: Viva Goals er avviklet (2024). Se Oboard eller Quantive for Azure DevOps-integrasjon.
• Oboard: OKR Board for Jira
• SAFe: PI Objectives
• The Burn Down: OKRs vs PI Objectives in SAFe

Relaterte ressurser i denne skillen

• okr-framework.md – Grunnleggende OKR-metodikk
• meeting-guides.md – Agendaer for OKR-møter (inkl. sprint planning med OKR)
• okr-implementation.md – Innføringsguide
• okr-offentlig-governance.md – Kobling til tildelingsbrev og politisk styring