Backlogg

Anbefalt Epic-struktur (mål- og verdifokusert)

Epic-tittel

Beskriver mål / ønsket effekt, ikke løsning, ikke teknisk

Beskrivelse (obligatorisk)

Formålet er å beskrive kontekst og retning

• Hvorfor finnes denne Epicken?
• Hva er dagens problem/situasjon?
• Hvem berøres?
• Kort og presist (3–6 linjer).

Eksempel: Denne epicken skal gi saksbehandlere bedre oversikt over aktiviteter i en undersøkelse, slik at planlegging og oppfølging blir enklere og mer forutsigbar.

Behov / problem som skal løses (obligatorisk)

Formålet er å avgrense omfanget.

Dette er IKKE detaljerte krav, men:

• Hvilke brukerbehov
• Hvilke problemer
• Hvilke mangler i dagens løsning

Eksempel:

• Mangler samlet oversikt over aktiviteter per undersøkelse
• Vanskelig å se status og rekkefølge
• Lite støtte for oppfølging over tid

Unngå «Systemet skal …»-setninger her.

Mål / verdi (obligatorisk)

Formålet er å begrunne prioritering.

Her svarer du på hvorfor er dette verdt å gjøre. Bruk gjerne både kvalitativ og kvantitativ verdi.

Eksempel:

• Redusert tidsbruk for saksbehandlere
• Færre feil og misforståelser
• Bedre beslutningsgrunnlag
• Økt forutsigbarhet i gjennomføring

Dette er ofte det viktigste feltet for PO/ledelse.

Avgrensninger / ikke-mål (sterkt anbefalt)

Formålet er å hindre scope creep. Dette er ofte mer verdifullt enn detaljerte krav.

Eksempel:

• Omfatter ikke rapportering på tvers av undersøkelser
• Omfatter ikke automatisering av aktiviteter
• Erstatter ikke eksisterende fagsystemer

Vedlegg / referanser (valgfritt, men bra)

Formålet er å belyse konteksten.

• Prosessdiagram
• Skisser
• Juridiske dokumenter
• Referanser til eksisterende systemer

Dette skal ikke være styrende krav, bare støtte.

Akseptansekriterier (med forbehold)

Her er det viktig å være presis:

Ikke anbefalt på Epic-nivå: Detaljerte, testbare akseptansekriterier og «Gitt–Når–Så» på Epic

Anbefalt på Epic-nivå: Overordnede ferdig-kriterier (Definition of Done for Epic)

Eksempel:
Epicken anses som levert når:

• Alle planlagte aktiviteter kan vises per undersøkelse
• Brukere kan se status og grunnleggende detaljer
• Løsningen er tatt i bruk av minst én pilotgruppe

Detaljerte akseptansekriterier hører hjemme på Feature eller Story.

Sammendrag – justert Epic-mal

Epic inneholder:

• Beskrivelse
• Behov / problem
• Mål / verdi
• Avgrensninger (anbefalt)
• Vedlegg / referanser
• Overordnede ferdig-kriterier (ikke detaljerte tester)

Epic inneholder IKKE:

• Tekniske løsninger
• Detaljerte krav
• Testbare brukerflyter

Hvis det kan testes automatisk = for lavt nivå for Epic

FEATURE-mal

Hvis Epic svarer på hvorfor og hva som er målet, svarer Feature på hva som faktisk bygges.

Anbefalt Feature-struktur

Feature-tittel

• Starter ofte med et verb
• Beskriver konkret funksjon
• Fortsatt bruker-/forretningsspråk

Eksempler:

• Vis aktiviteter per undersøkelse
• Filtrere innmeldinger etter status
• Redigere aktiviteter i en undersøkelse

Beskrivelse (obligatorisk)

Formålet er å forklare funksjonen i kontekst av Epicken

• Hva gjør denne featuren?
• Hvordan støtter den Epicken?
• Hvem bruker den?

Eksempel: Denne featuren gir saksbehandler mulighet til å se alle aktiviteter knyttet til en valgt undersøkelse i én samlet visning.

Mer konkret enn Epic, men fortsatt uten tekniske valg.

Funksjonelt omfang (obligatorisk)

Formålet er å fortelle hva som inngår i featuren

Dette er krav på funksjonsnivå, men ikke UI-pixel eller teknisk.

Eksempel:

• Vise liste over aktiviteter per undersøkelse
• Vise status for hver aktivitet
• Vise grunnleggende metadata (type, ansvarlig, frist)

Her er «systemet skal …» helt greit.

Avgrensninger / ikke-omfang (sterkt anbefalt)

Formålet er å beskytte scope

Eksempel:

• Inkluderer ikke redigering av aktiviteter
• Inkluderer ikke varsling
• Inkluderer ikke rapportering på tvers av undersøkelser
• Dette gjør Feature mye lettere å estimere og ferdigstille.

Brukerflyt / scenarioer (anbefalt)

Formålet er å gjøre funksjonen forståelig ved å beskrive 1–3 typiske scenarioer

Ikke full BDD (beskrive hvordan systemet skal oppføre seg i konkrete situasjoner, sett fra brukerens ståsted), bare flyt

Eksempel:

Saksbehandler åpner en undersøkelse → velger fanen «Aktiviteter» → ser liste sortert etter frist.

Akseptansekriterier (obligatorisk)

Formålet er entydig ferdig-definisjon

Her er det riktig nivå for testbare kriterier.

Eksempel (Given–When–Then):

• Gitt at en undersøkelse har flere aktiviteter
• Når saksbehandler åpner aktivitetsoversikten
• Så vises alle aktiviteter tilknyttet undersøkelsen
• Gitt at en aktivitet er fullført
• Når listen vises
• Så vises korrekt status

Avhengigheter / forutsetninger (valgfritt)

Formålet er planlegging

Avhenger av annen Feature/Epic

Krever data, tilgang, beslutning

Vedlegg / referanser (valgfritt)

Skisser
Prototyper
API-kontrakter
Prosessdiagram (utdrag)

Epic vs Feature – tydelig skille

Element:	Epic	Feature
Fokus:	Mål / effekt	Funksjon
Tidshorisont:	Flere iterasjoner	1-2 iterasjoner
Løsningsnivå:	Lavt	Middels
Akseptansekriterier:	Overordnede ferdig-kriterier	Testbare kriterier
Krav:	Behov	Funksjonelle krav
Brukes til:	Prioritering	Leveranse

Tommelfingerregler:

• Handler det om hvorfor? → Epic
• Kan det estimeres presist? → Feature
• Kan det testes automatisk? → Feature
• Handler det om hva bygges nå? → Feature

Eksempel på kobling:

• Epic: Strukturert oversikt over aktiviteter i en undersøkelse
• Feature 1: Vise aktiviteter per undersøkelse
• Feature 2: Vise status og frister for aktiviteter
• Feature 3: Filtrere aktiviteter etter status

Epic – eksempel

Epic-tittel: Klar rollefordeling i klassesystemet

Beskrivelse

I dag er rollebruk og tilgang i klassesystemet utydelig og delvis inkonsekvent, noe som fører til usikkerhet rundt ansvar, feilbruk av funksjonalitet og økt risiko for feil håndtering av meldinger.

Denne epicken skal etablere en tydelig og felles forståelse av roller og tilhørende ansvar i klassesystemet, slik at brukere har riktig tilgang og vet hva de kan og skal gjøre.

Behov / problem som skal løses

• Brukere har tilgang til funksjoner de ikke trenger
• Uklart ansvar for håndtering av meldinger
• Inkonsekvent rollebruk på tvers av enheter/team
• Vanskelig å forstå hvilke roller som finnes og hva de innebærer

Mål / verdi

• Økt sikkerhet gjennom riktig tilgang
• Redusert risiko for feil håndtering av meldinger
• Mer effektiv arbeidsflyt for brukere
• Bedre etterlevelse av interne retningslinjer og regelverk
• Enhetlig praksis for rollebruk i hele organisasjonen

Avgrensninger / ikke-mål

• Epicken omfatter ikke teknisk tilgangsstyring i underliggende infrastrukturer
• Omfatter ikke opplæringsmateriell utover nødvendig støtte i løsningen
• Erstatter ikke eksisterende autorisasjonsløsninger utenfor klassesystemet

Vedlegg / referanser

• Nåværende rolleoversikt (dokument)
• Prosessbeskrivelse for meldingshåndtering
• Relevante interne retningslinjer for tilgang og ansvar

Overordnede ferdig-kriterier (Epic DoD)

Epicken anses som levert når:

• Roller i klassesystemet er definert og dokumentert
• Brukere har tilgang basert på tydelige roller
• Rollebruk oppleves konsistent av sluttbrukere

Minst én målgruppe har tatt løsningen i bruk uten behov for manuelle avklaringer

Hvorfor dette er en god Epic

✔ Tittelen beskriver mål og effekt
✔ Beskrivelsen gir kontekst uten løsning
✔ Behov ≠ krav
✔ Verdi er eksplisitt formulert
✔ Akseptansekriterier er overordnede, ikke testcases
✔ Kan brytes ned i flere Features naturlig

Eksempel på tilhørende Features

For å vise skillet tydelig:

• Definere roller i klassesystemet
• Tilordne funksjonalitet per rolle
• Vise rolle og ansvar til bruker
• Begrense tilgang basert på rolle