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](#okr--scrum)
2. [OKR + Kanban](#okr--kanban)
3. [OKR + Prosjektportefølje](#okr--prosjektportefølje)
4. [OKR + SAFe](#okr--safe-skalert-agile)
5. [Verktøyintegrasjon](#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 — fiktiv eksempeletat)
├── 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 syklusvise 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 (fiktiv eksempeletat)

```
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](https://okrinstitute.org/unlocking-synergy-how-to-align-okrs-and-scrum-for-maximum-impact/)
- Scrum.org: [How OKRs and Scrum Work Together](https://www.scrum.org/resources/blog/how-okrs-and-scrum-work-together-drive-strategic-execution)
- Mooncamp: [OKR and Agile](https://mooncamp.com/blog/okr-and-agile)
- Martin Fowler: [Team OKRs](https://martinfowler.com/articles/team-okr.html)
- Atlassian: [OKR in Jira and Confluence](https://www.atlassian.com/blog/add-ons/okr-jira-confluence)
- Microsoft Learn: Viva Goals er avviklet (2024). Se Oboard eller Quantive for Azure DevOps-integrasjon.
- Oboard: [OKR Board for Jira](https://oboard.io/okr-board-for-jira)
- SAFe: [PI Objectives](https://scaledagileframework.com/pi-objectives/)
- The Burn Down: [OKRs vs PI Objectives in SAFe](https://theburndown.com/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