Team Autorisasjon · ADR-0005
Én tavle,
én visning
per rolle
Slik flyter arbeidet fra idé til produksjon, og hva hver rolle ser på tavlen
Basert på docs/adr/0005-planning-and-flow.md og 0005-board-views.md
Grunnregelen
Hver rolle har sin egen issue på tavlen.
Du får den når den forrige er lukket.
Du lukker den når din del er ferdig.
Derfor skjer de fleste flyttingene på tavlen av seg selv, og tavlen er alltid sannheten om hvor arbeidet står.
Sprinten
To uker, felles for begge team
Mandag
Tirsdag
Onsdag
Torsdag
Fredag
Uke 1
åpner
Uke 2
lukker
Planlegging
Felles: to–tre sprintmål
Per område: hvem gjør hva
Prod-deploy
Status
Per område · 60 min
TT02-deploy
Raffinering
Ved behov, per område
Status
Per område · 30 min
Status
Per område · 30 min
Prod-deploy
Status
Per område · 60 min
TT02-deploy
Prioritering
45 min · bekrefter listen for neste sprint
Resultatmøte
45 min · alt uferdig får en beslutning
Retro
Møtene erstatter grooming, teammøte og fredagsmøte. Status er alltid per område, aldri hele teamet.
Inntak
Slik kommer arbeid inn
1
Idé
Hvem som helst lager en issue med skjemaet. Den lander i Backlog med status/triage.
2
Triage
Innen en uke: den som står nærmest, setter type og area/*.
3
Prioritering
Torsdag i uke 2: vi bekrefter listen for neste sprint og velger kandidater for sprinten etter.
4
Raffinering
Sprinten før: vi deler featuren i oppgaver med akseptansekriterier. Det som kan starte, går til Ready.
5
Planlegging
Tar bare raffinerte features. Mangler raffinering, venter featuren én sprint.
Hvem triagerer?
Områdeeieren
Det som lander i området, senest i neste raffinering.
Den som fant det
Egne funn. En liten fiks under en halv dag kan gå rett til In progress.
Vakten
Det som kommer fra Slack eller CRM uten et åpenbart område.
Ingen etter en uke
Områdeeieren for nærmeste område tar det i raffinering.
Rytme
Raffinering og design går én sprint foran
Sprint N−1
Sprint N
Sprint N+1
Prioritering
Raffinering
Design
Bygg og test
Bekrefter A for sprint N
Raffinerer A
A: designoppgaven starter
Bygger og tester A
Bekrefter B for sprint N+1
Raffinerer B
B: designoppgaven starter
Bygger og tester B
Bekrefter C for sprint N+2
Raffinerer C
C: designoppgaven starter
Oppgaver under samme feature kan ligge i ulike sprinter. Kjeden bryr seg bare om at noe blir lukket.
Flyten
Fra prioritert feature til lukket feature
Feature prioritert
Produkteier
Raffinering
Delt i oppgaver per rolle
Design
Lukket når den er god nok å bygge
Backend
Merge lukker den
Frontend
Venter på design
Test av én oppgave
Når den er merget
Test av featuren
Når alle er merget
Feature lukket
Godkjent og i produksjon
Én regel: en issue dukker opp i Ready når det den venter på er lukket.
Kjeden
Kjeden går nesten av seg selv
Sub-issues
Testoppgaven er sub-issue av featuren og venter på alle de andre.
Blocked by
Frontend som trenger designet er «blocked by» designoppgaven.
Lukking
Den som lukker, gjør overleveringen: en flytting eller en omtale.
Animasjonen viser én feature med fem sub-issues.
Overleveringer
Hver overlevering for én feature
1
Produkteier → områdeeier
Når featuren får milestone
Nå: områdeeieren ser den i Features-visningen.
Senere: en kommentar til områdeeieren
2
Områdeeier → teamet
Når raffineringen er ferdig
Nå: områdeeieren flytter det som kan starte til Ready.
Senere: forblir manuelt, Ready er en vurdering
3
Designer → frontend
Når designoppgaven er lukket
Nå: designeren flytter frontend-oppgavene som ventet, til Ready.
Senere: Action-en flytter dem
4
Utvikler → tester
Når siste utvikleroppgave er merget
Nå: utvikleren nevner testeren, som flytter kortet til Executing.
Senere: Action-en setter fase og kommentar
5
Tester → designleder
Når testen går til Executing
Nå: testeren legger til designleder som andre assignee.
Senere: tildelingen skjer automatisk
6
Tester → produkteier
Når featuren er lukket etter prodsjekk
Nå: epicens sub-issue-teller går av seg selv.
Senere: ingenting mer trengs
Feil i test blir en bug som sub-issue av featuren, og havner i utviklervisningen av seg selv.
Test
Testforberedelse går parallelt med utviklingen
Uke 1
Uke 2
Ma
Ti
On
To
Fr
Ma
Ti
On
To
Fr
Utvikling
Test
Designreview
Backend
Frontend
Preparing · testdata, testtilfeller, verktøy, miljø
Siste merge: utvikleren nevner testeren
Executing i AT
Mot siste design
Bug
Bug lukket: testeren setter Retest
Retest
Begge godkjent
Test phase-feltet viser fasen: Preparing → Executing → Retest. Testeren lukker testoppgaven når både testeren og designlederen har godkjent.
Fremdrift
Du leser fremdriften i sub-issues
Design
Designoppgave
Utvikler
Utvikleroppgave 1
Utvikler
Utvikleroppgave 2
Utvikler
Utvikleroppgave 3
Test
Testoppgave · kind/testplan
Lukket
Lukket
Lukket
Lukket
Åpen
Feature med fem direkte sub-issues
4 av 5
med én åpen betyr som regel: venter på test
Telleren tar med design- og testoppgaver. En epic teller featurene sine på samme måte.
Tavlen
Én tavle for begge team, fem kolonner
Backlog
Kjent, ikke planlagt
Ready
Øverste issue er den riktige å ta
In progress
Få aktive per person, ingen hard grense
In review
Pull request åpen
Done
Lukket
#4292 · Task
#4292 · Task
#4292 · Task
#4292 · Task
#4292 · Task
Ny issue havner på tavlen
Områdeeieren flytter
Utvikleren drar
PR åpnet
Merge lukker
Innebygd automatikk
Ny issue fra repoet havner på tavlen
Lukket issue går til Done
Gjenåpnet issue går til In progress
Prosjektet arkiverer Done-kort etter resultatmøtet
Feltene
Ett spørsmål per mekanisme
| Mekanisme | Svarer på | Slik bruker vi den |
|---|---|---|
| Iteration | Hvilken sprint | Tosukerssprinten. Sprinttavlen filtrerer på den. Vi setter den i planleggingen |
| Milestone | Hvilket datert mål | Veikartmål med frist. Featuren får den den må være med i |
| Priority | I hvilken rekkefølge | Rekkefølge i nåværende og neste sprint. urgent krever en dato |
| Labels | Hva slags, hvor | Type, area/*, kind/*. Klassifisering, aldri planlegging |
| Epic | Hvilket mål | Grupperer features for ett veikartpunkt. Ingen egen dato |
| Test phase | Hvor en test står | Preparing, Executing, Retest. Bare på testoppgaver |
Ingen eget horisontfelt: tavlen viser tre horisonter
Nå
Nåværende iterasjon
Neste
Milestone uten iterasjon
Senere
Ingen milestone
Visningene
Sju lagrede visninger av samme tavle
Én tavle for begge team
Hver visning er et lagret filter og et kolonnefelt
Sprint
Alle
Tavle · Status
Utviklere
Utviklere
Tavle · Status
Test
Testere
Tavle · Test phase
Design
Designere
Tabell
Features
Produkteiere og ledere
Tabell
Område
Områdeeier
Tavle · per feature
Vakt
Den som har vakt
Tavle · Status
Neste lysbilder viser hver visning med eksempel-issuene fra ADR-en. Issuene er oppdiktede, filtrene er de ekte. Vi lager flere visninger bare når noen ber om det.
Visning 1 av 7 · Alle
Sprinttavlen, standardvisningen
iteration:@current
Kolonner: Status · sortert på Priority
Ready · 3
In progress · 5
In review · 2
Done · 4
#4292 · Task
Add via-party mode to Authorize API
#4712 · kind/testplan
Test: Delegation overview end to end
#4701 · kind/design
Design: Consent dialog, rights selection
#3899 · Task · PR #3925
ConnectionQuery: prune on resource filter
#3745 · status/blocked
Change feed sync in Access Management
#4698 · kind/testplan
Test: Rights selection on approval
#4688 · kind/design
Design: System user delegation flow
#4269 · Bug
RDF export omits contact points
#3296 · Task · PR #2283
Query param for party switch, system user
#4511 · Bug · PR #2131
Enduser-api: delegated clients 500
#4605 · merget
Backend: approval limited to RightKeys
#4606 · godkjent
Test: Approval limited to RightKeys
#3655 · merget
Drop old AM database schemas
#4650 · kind/design
Design: Activity log pagination
Eneste visning der design-, utvikler- og testoppgaver står side om side.
Ingen Backlog-kolonne: alt her er i sprinten.
Visning 2 av 7 · Utviklere
Utviklere: bare oppgaver og bugs
type:Task,Bug -label:kind/testplan -label:kind/design iteration:@current
Kolonner: Status · sortert på Priority
Ready · 2
In progress · 3
In review · 2
Done · 1
#4292 · high · ↑ #4290
Add via-party mode to Authorize API
#4610 · ↑ #4603 · frigjort
Frontend: select rights on request
#3899 · PR #3925 åpen
ConnectionQuery: prune on resource filter
#3745 · venter på Team Core
Change feed sync in Access Management
#4269 · Bug · ↑ #4100
RDF export omits contact points
#3296 · PR #2283
Query param for party switch, system user
#4511 · Bug · PR #2131
Enduser-api: delegated clients 500
#4605 · merget 09:40
Backend: approval limited to RightKeys
Parent-featuren (↑) står på hvert kort, så ingen tar en oppgave uten å vite hvilken feature den tjener.
In review betyr: ta neste. Kortet forlater ved merge, ikke ved godkjenning.
Visning 3 av 7 · Testere
Testtavlen: kolonnene er Test phase
label:kind/testplan is:open
Kolonner: Test phase, ikke Status
No phase · 1
Preparing · 2
Executing · 2
Retest · 0
#4712 · ↑ #4700 · neste sprint
Test: Delegation overview end to end
#4698 · ↑ #4603
Test: Rights selection on approval
#4713 · ↑ #4292 Task
Test: Via-party mode, alone
#4606 · ↑ #4603
Test: Approval limited to RightKeys
#4690 · bug #4740 meldt
Test: System user delegation flow
Utviklerens omtale kl. 09:40 var signalet: testeren dro #4606 til Executing, og designleder ble lagt til.
Done er ikke en kolonne. En lukket testoppgave forsvinner fra visningen.
På sprinttavlen står de fleste av disse i In progress. Her er det fasen som teller. Hvor nær en feature er utførelse, ser du i Features-visningen.
Visning 4 av 7 · Designere
Design jobber én sprint foran
label:kind/design is:open
Tabell · sortert på Iteration, så Status
| Tittel | Parent | Status | Iteration | Milestone | Blokkerer |
|---|---|---|---|---|---|
| #4688 Design: System user delegation flow | #4688 Feature | In progress | 2026-11-09 | 2026-12 | #4690, #4691 |
| #4701 Design: Consent dialog, rights selection | #4700 Feature | Ready | 2026-11-09 | 2026-12 | #4703 |
| #4650 Design: Activity log, empty state iteration | #4650 Feature | Ready | 2026-11-23 | 2027-01 | — |
Én sprint foran
Rad to hører til en feature utviklerne bygger neste sprint. Designoppgaven er i denne.
Blokkerer viser hva som venter
Når rad én er lukket, flytter designeren #4690 og #4691 til Ready for frontend.
Designgjeld
Rad tre er en liten oppfølging, opprettet etter designreview.
Visning 5 av 7 · Produkteiere, designleder, tech leads og områdeeiere
Features: fremdrift uten oppgaver
type:Epic,Feature is:open
Tabell · sortert på Milestone, så Priority
Tittel
Type
Milestone
Priority
Status
Sub-issues
Remove Altinn 2 roles
Epic
2027-01
high
In progress
Approval limited to RightKeys
Feature
2026-12
high
In progress
Delegation overview
Feature
2026-12
normal
Ready
System user delegation flow
Feature
2026-12
normal
In progress
Bulk revoke
Feature
—
—
Backlog
—
Move to DIS
Epic
2027-03
normal
Backlog
2 av 5 features
4 av 5 · test åpen
0 av 6
1 av 4
0 av 3 features
Ingen oppgaver her. Telleren tar med design og test, så «4 av 5» med én åpen betyr som regel: venter på test.
Du ser Backlog som features uten milestone. Når produkteieren setter milestone, er det signalet til områdeeieren om at raffinering er neste.
Visning 6 av 7 · Områdeeier
Område: kjeden per feature
label:area/<name> is:open
Tavle · Status · gruppert på Parent issue
Ready
In progress
In review
Done
#4603 Feature · Approval limited to RightKeys · 2026-12 · 4 av 5 lukket, testoppgave åpen
#4606 · Test
#4605 · Backend
#4611 · Frontend
← Venter bare på testeren
#4700 Feature · Delegation overview · 2026-12 · raffinert, kommer i neste sprint
#4701 · Design
#4702 · Backend
← Nettopp raffinert: de første oppgavene er flyttet til Ready for hånd
#4720 Feature · Bulk revoke · ingen milestone · Backlog, ikke raffinert
Her ser områdeeieren hva som står for tur til raffinering. Tilbyr ikke menyen gruppering på Parent issue, sorter på den i stedet: oppgavene havner likevel sammen.
Visning 7 av 7 · Vakt
Vakt: på tavlen, men utenfor sprinten
label:kind/question,kind/incident is:open
Tavle · Status · ingen iterasjon
Backlog
In progress
Done
#4731 · question
Vendor asks: why is delegation rejected for org X
Fra Slack
#4728 · question
CRM 48812: client delegation not visible
Oppgave #4729 opprettet
#4733 · incident
Authorize API 5xx spike, AT
I sprinten, forbi Ready
Backlog er en kolonne her: mottatt, men ikke startet, er en reell tilstand for en vaktsak.
Hendelsen står også på sprinttavlen fordi den fikk nåværende iterasjon. Spørsmålene gjør ikke det.
Sak fra Slack eller CRM
Issue med kind/question eller kind/incident og area/*, på tavlen uten iterasjon
Trenger kode?
Vakten lager en oppgave eller bug under riktig feature
Hendelse?
Rett til In progress i sprinten, forbi Ready
Vakten lukker saken når den er besvart eller løst. Hendelser tar vi opp i resultatmøtet.
Her ser du Backlog
Backlog står bare i visningene der noen gjør noe med en issue som ikke er startet.
Sprint
Ingen Backlog
Utviklere
Ingen Backlog
Test
Ingen Backlog
Design
Ingen Backlog
Features
Viser Backlog
Område
Viser Backlog
Vakt
Viser Backlog
Produkteier og områdeeier raffinerer derfra, og vakten tar imot saker der. Alle andre ser bare det som er i sprinten.
Avtaler
Klar til å starte, og ferdig
Definition of Ready
Områdeeieren kan flytte en feature til Ready når
den har prioritet og milestone, og hører til en epic der en finnes
den er delt i design-, backend-, frontend- og testoppgaver med testbare akseptansekriterier
designet ligger i featuren, eller designoppgaven er opprettet
minst én av oppgavene blir lukket i sprinten featuren starter i
Definition of Done
En oppgave er ferdig når den er merget
Automatiske tester er grønne, og pull requesten lukker oppgaven.
En feature er ferdig når
alle oppgavene er merget, designreview er godkjent for endringer brukerne ser, testoppgaven er lukket med godkjent resultat, og endringen er i produksjon.
Arbeid du ikke kan dele opp: del det i arbeidssteg, ikke etter hva du kan levere. Nytt skjema, migrer data, bytt lesing, fjern gammel vei: fire oppgaver du lukker etter hverandre. Vi kutter ingenting mindre enn det er bare for å få det inn i en sprint.
Veien videre
Overleveringer for hånd først, en Action senere
Innebygd nå
Ny issue fra repoet havner på tavlen
Lukket issue går til Done
Gjenåpnet issue går til In progress
Prosjektet arkiverer Done-kort etter resultatmøtet
For hånd i første iterasjon
Designeren flytter ventende frontend-oppgaver til Ready
Utvikleren nevner testeren i testoppgaven
Testeren setter Test phase
Testeren legger til designleder
Senere: handoff-Action
Når en issue blir lukket, flytter den det som ventet, til Ready
Den flytter testoppgaven til Executing
Den legger til designleder
Beskrevet i #4088. Den kommer først når labels og skjema er på plass, siden den matcher på dem.
Vi bestemmer senere: release-flyten til TT02 og produksjon, hotfix, og om deploy-workflowen kan merke issues med prod og lukke features.
Vi starter
med dette
og ser etter de første sprintene hva som mangler.
Prosessen: docs/adr/0005-planning-and-flow.md
Visningene: docs/adr/0005-board-views.md
Tavleoppsett og Action: altinn-auth #4088