Begreper

Akseptansekriterier definerer hva som er akseptabelt og ikke akseptabelt opp mot prosjektets styringsparametere. 

Kriteriene bør knyttes til tid, kostnad, kvalitet, omfang, bærekraft, nytte og risiko der det er relevant. De bør beskrives med målbare størrelser eller tydelige vurderingskriterier så langt det lar seg gjøre. I tillegg benyttes akseptansekriterier i produktbeskrivelsen til å beskrive hva som må være oppfylt for at produktet kan godkjennes innenfor prosjektets rammer. 

I Prosjektveiviseren er det seks beslutningspunkter, som er sentrale handlingspunkter mot slutten av hver fase. I hvert beslutningspunkt avgjøres det om prosjektet skal gå videre til neste fase, endre planer eller gjennomføring, utsette varighet i nåværende fase eller avsluttes. Beslutningspunktene gir prosjekteier og ledelse mulighet til å vurdere om prosjektet fortsatt er relevant, om målene er tydelige, om risikoen er akseptabel, og om forventet nytte fortsatt forsvarer videre investering.   

Bærekraft handler om hvordan prosjektet og prosjektets leveranser påvirker miljømessige, sosiale og økonomiske forhold. I Prosjektveiviseren er bærekraft ett av prosjektets syv styringsparametere. Når vi referer til bærekraft, gjelder det ett eller flere av FNs bærekraftsmål. 

Bærekraftstrategien beskriver hvilke tiltak, vurderinger og kontroller prosjektet skal bruke for å følge opp bærekraftsmålene. Den gjelder både prosjektarbeidet og produktene eller leveransene prosjektet skal fremskaffe. 

Daglig logg brukes til å fange opp problemer, bekymringer og andre forhold som prosjektleder kan håndtere uformelt. 

Data- og digitaliseringsstrategi beskriver hvordan teknologi skal brukes til å støtte prosjektarbeidet, og hvordan data og informasjon skal opprettes, brukes, deles og forvaltes gjennom prosjektet. 

Ekstern kvalitetssikring er en uavhengig vurdering utført utenfor prosjektorganisasjonen, for å vurdere om prosjektets produkter er egnet til formålet, eller om de oppfyller definerte krav. 

Kvalitetssikringen kan gjennomføres av virksomheten som eier prosjektet eller av en ekstern tredjepart. Omfanget bør tilpasses prosjektets størrelse, kompleksitet og risiko. 

Endringsledelse handler om å lede ansatte og organisasjonen gjennom en endringsprosess, slik at virksomheten oppnår forventede resultater og nyttevirkninger. I praksis omfatter det blant annet å sikre ledelsesforankring, involvering, tydelig kommunikasjon, og nødvendig kompetanse både i prosjektorganisasjonen og i relevante miljøer utenfor som skal ta imot produkter eller leveranser fra prosjektet.  

Vær oppmerksom på at endringsledelse ikke må forveksles med det å styre endringer i prosjektets omfang og leveranser. Det er heller ikke det samme som kontrollert endring av programvare i et driftsmiljø (change management). 

Erfaringsloggen brukes til å samle erfaringer underveis i prosjektet. Erfaringene kan brukes senere i samme prosjekt eller i fremtidige prosjekter. 

Evaluering er en vurdering av prosjektets forløp, resultater og erfaringer. Både det som fungerte godt, og det som fungerte mindre godt, bør vurderes. Evalueringen gir grunnlag for læring i prosjektet og for senere prosjekter. 

En faseplan er en detaljert plan for styring og oppfølging av en fase. Prosjektet kan ha faseplan for planleggingsfasen, gjennomføringsfasen og avslutningsfasen. 

Formelle saker er saker som krever eskalering og beslutning på et høyere styringsnivå. Dette er forhold prosjektleder ikke har myndighet til å avgjøre selv, og som derfor må behandles formelt av prosjekteier eller prosjektstyret. 

En interessent er en person, gruppe eller organisasjon som kan påvirke prosjektet, bli påvirket av prosjektet, eller oppfatter at de blir påvirket av prosjektets gjennomføring eller resultater. 

Interessentregisteret inneholder samlet informasjon om prosjektets interessenter. Det bør vise hvem interessentene er, hvilken tilknytning de har til prosjektet, hvilke interesser og behov de har, hvilken innflytelse de kan ha, og hvordan de skal følges opp. Registeret må oppdateres jevnlig. 

Intern kvalitetssikring er prosjektstyrets ansvar for å sikre at prosjektet gjennomføres i tråd med god praksis. Prosjektstyrets medlemmer har et ansvar for intern kvalitetssikring innenfor sine perspektiver. Prosjekteier har særlig ansvar for at prosjektet beholder fokus på nyttevirkninger.

Kommunikasjonsstrategien beskriver hvordan prosjektet skal kommunisere med aktører i og utenfor prosjektet. Den skal bidra til god involvering, tydelig informasjon og en styrt, toveis informasjonsflyt. 

Tekniske og administrative aktiviteter knyttet til etablering, vedlikehold og endring av konfigurasjon av produkter gjennom produktets livssyklus.

Et annet begrep for konfigurasjonsstryring kan være versjonshåndtering.

Konfigurasjonsstrategien beskriver hvordan prosjektets produkter skal kontrolleres, lagres, beskyttes og versjonshåndteres. Den beskriver også hvordan endringer skal håndteres, og hvem som har ansvar for konfigurasjonsstyringen. 

Kvalitetskriterier beskriver hvilke krav et produkt eller en leveranse skal oppfylle for å ha riktig kvalitet. De kan for eksempel gjelde funksjon, ytelse, nøyaktighet, brukervennlighet, sikkerhet eller tilgjengelighet. 

Kvalitetsstrategien beskriver hvilke kvalitetsteknikker, standarder, roller, ansvar, verktøy og kontroller som skal brukes i prosjektet. Den viser hvordan prosjektet skal sikre at leveransene får riktig kvalitet. 

Kvalitetstoleranser angir hvor store avvik som er tillatt fra fastsatte kvalitetskrav. De viser hvor mye kvaliteten kan variere før avviket må håndteres eller løftes til et høyere styringsnivå.  

Kvalitetstoleranser bør inngå i akseptansekriteriene for prosjektets produkter. De gjør det tydelig hva som er godt nok til å bli godkjent, og hvor grensen går for hva prosjektleder kan akseptere uten ny beslutning. 

En løsningsbeskrivelse beskriver hva en løsning skal gjøre og hvordan den er bygget opp.

En funksjonell løsningsbeskrivelse beskriver løsningen fra et brukerperspektiv.

En teknisk løsningsbeskrivelse beskriver hvordan funksjonaliteten er implementert teknisk, fra et leverandørperspektiv. 

Et Mandat for konseptfasen er et ledelsesprodukt som etableres av organisasjonen som eier og iverksetter et prosjekt. Det utarbeides på bakgrunn av et oppdrag, en strategisk satsning eller et forslag til å løse et problem eller et behov. Det gir de som skal gjennomføre utredningsarbeidet/konseptfasen et mandat til å sette i gang sitt arbeide, herunder føringer og rammer for arbeidet i konseptfasen.

Nyttestyring er en metode for å utrede, planlegge, gjennomføre og følge opp prosjekter og dets leveranser slik at avsatte midler og ressurser brukes til det beste for virksomhet og samfunnet. Det innebærer å vurdere nyttevirkninger (positive virkninger) og kostnadsvirkninger (negative virkninger) av alternative tiltak og aktivt bruke vurderingen av om tiltaket er samfunnsøkonomisk lønnsomt, gjennom hele prosjektet og etter overleverelse av prosjektets resultater.  

Denne definisjonen tar utgangspunkt i DFØ sin definisjon av nyttestyring. Les mer i DFØ sin Veileder om nyttestyring for statlige tiltak.

Nyttevirkninger er de positive virkningene virksomheten forventer at prosjektet skal bidra til. Nyttevirkninger kan for eksempel være bedre tjenester, mer effektiv ressursbruk, høyere kvalitet, bedre etterlevelse av regelverk eller redusert risiko. Nyttevirkninger må beskrives og måles opp mot satte akseptansekriterier, og følges opp ved aktiv nyttestyring også etter at prosjektet er avsluttet. 

Nyttevirkninger blir også kalt positive virkninger, effekter, fordeler eller gevinster. 

Prosjektveiviseren gikk i 2026 over til å benytte “nyttevirkninger” fremfor “gevinster”, for å samsvare med DFØ sin veileder om nyttestyring for statlige tiltak. “Gevinster” omtales fortsatt, men det er nyttevirkninger som i hovedsak benyttes.  

Omfang beskriver hva prosjektet skal levere, og hva som ikke inngår i prosjektet. Omfanget bør være tydelig nok til at prosjektet, prosjekteier, brukere og leverandører har en felles forståelse av hva prosjektet skal dekke. 

En portefølje er den samlede oversikten over en virksomhets initiativer og tiltak, for eksempel prosjekter, programmer, produkter og andre aktiviteter i linja. Porteføljestyring handler om å prioritere tiltak, fordele ressurser og sikre at virksomheten bruker kapasiteten på det som gir størst verdi. 

Prosjektveiviseren er rettet mot styring av de enkelte prosjektene og er ikke i seg selv ment å ivareta virksomhetens behov for porteføljestyring. Imidlertid vil porteføljestyringens prioritering og koordinering av hele porteføljen ha en klar kobling mot konklusjonene fra prosjektveiviserens beslutningspunkter; og da i særlig grad de tidlige beslutningspunktene BP1 og BP2.

Et produkt i Prosjektveiviseren er noe som leveres fra en prosjektfase, eller noe som brukes i en prosjektfase. Produkter er definerte deler av en prosjektleveranse som kan kvalitetskontrolleres og leveres. Et prosjekt kan ha flere produkter, og det kan være både produkter som benyttes underveis i prosjektet, i tillegg til å inngå i det samlede prosjektresultatet.  

Det er en forskjell på prosjektets produkter, og produkter som utvikles av produktteam i en produktorganisering. I et prosjekt er produkter leveranser som prosjektet skal fremskaffe innenfor et mandat, en tidsramme og noen beslutningspunkter. I produktorganisering er produktet noe et produktteam eier og videreutvikler kontinuerlig over tid, uten en fast sluttdato (produktet kan likevel avvikles dersom det ikke lenger fører til tenkt nyttevirkning eller må prioriteres ned av andre grunner).  

Samtidig er det en sammenheng mellom produkter i disse to styringsformene. Prosjekter kan utvikle, forbedre eller etablere et produkt som overføres til et produktteam for videre drift, videreutvikling, oppfølging og prioritering. Det er hensiktsmessig og anbefalt at et eller flere medlemmer i produktteamet som overtar produktet fra prosjektorganisasjonen, er en eller flere av de samme som utviklet produktet i prosjektet. Dette for å sikre helhetlig forståelse og kontinuitet. 

I produktorganisering har produktteamet ansvaret for hele livsløpet til produktet, enten fra start (ide til løsning på et gitt problem/behov) eller etter overtakelse av et produkt fra et prosjekt. Derfor henger dette sammen, men det er omfanget av ansvaret (varighet) og organiseringen (styring) rundt produktet som varierer fra prosjekt- og produktorganisering.  

Les mer om produktorganisering og produktteam i Anbefaling for produktorganisering i offentlig sektor | Digdir.  

En produktbeskrivelse forklarer hensikten med et produkt, hva det består av, hva det bygger på, og hvilke kvalitetskriterier som gjelder. Produktbeskrivelser bør etableres så snart behovet for produktet er identifisert. 

Produktdokumentasjon er en av tre former for dokumentasjon i Prosjektveiviseren, og beskriver det produktene i prosjektet skal levere, kravene som gjelder for leveransene og hva som må være oppfylt for at prosjektets produkter godkjennes og kan tas i bruk. Produktdokumentasjonen skal bidra til felles forståelse av hva som skal utvikles, endres, innføres, driftes eller forvaltes.   

Produktdokumentasjonen består oftest av: Produktbeskrivelse og akseptansekriterier. 

Se prosjektkanvas dersom begrepet brukes om et prosjektstyringsverktøy. Dersom dere ønsker å bruke produktkanvas som eget begrep, bør det defineres som en kort og visuell beskrivelse av produktets målgruppe, behov, verdi, effektmål og overordnede retning. 

En produktnedbrytningsstruktur er en hierarkisk oversikt over alle produkter som skal produseres og som inngår i en plan. Den hjelper prosjektet med å få oversikt over hva som må leveres. 

Et program er en samling prosjekter og aktiviteter med et felles overordnet mål. Et program brukes når flere tiltak må styres samlet for å skape en større endring og realisere nyttevirkninger som ett enkelt prosjekt ikke kan oppnå alene. Et program har ofte varighet over flere år, og prosjektene kan gjennomføres etter hverandre eller delvis parallelt. 

Her kan du lese mer om programstyring.

Et prosjekt er en midlertidig organisasjon som er etablert for å levere ett eller flere produkter som bidrar til å realisere en avtalt begrunnelse. Prosjekter har vanligvis et tydelig mål, en avgrenset ramme for tid, kostnad og omfang, og en oppgave som skiller seg fra ordinær drift. 

Prosjektbegrunnelsen beskriver hvorfor prosjektet bør gjennomføres. Den viser sammenhengen mellom behovet, målene, anbefalt konsept, forventet nytte, kostnader og usikkerhet.

Prosjektbegrunnelsen brukes som grunnlag for å vurdere om prosjektet fortsatt er relevant og verdt å gjennomføre. Den videreutvikles gjennom prosjektet når ny informasjon kommer til.

Prosjektforslaget gir grunnlag for å vurdere om et mulig prosjekt bør planlegges videre. Det beskriver anbefalt konsept, forventet nytte, overordnede rammer, usikkerhet og behov for videre arbeid.

Prosjektforslaget brukes som beslutningsgrunnlag ved overgangen fra konseptfasen til planleggingsfasen. Dersom prosjektet går videre, erstattes prosjektforslaget normalt av styringsdokumentet eller et forenklet styringsdokument.

Et prosjektkanvas er en kort og visuell beskrivelse av prosjektets visjon, verdi, brukere, nyttevirkninger og rammer. Det kan brukes tidlig for å skape felles forståelse og som grunnlag for forenklet styring. 

Prosjektstyring er den delen av virksomhetens styring som gjelder prosjektaktiviteter. God prosjekteierstyring skal sikre at prosjektet støtter virksomhetens mål, at prosjektet styres etter god praksis, og at prosjekteier tar nødvendige beslutninger underveis. 

Prosjektplanen er en overordnet plan som viser hovedproduktene i prosjektet, når de skal leveres, og til hvilken kostnad. 

Prosjektproduktet er det samlede resultatet prosjektet må levere for å bli godkjent. Et prosjektprodukt består ofte av flere prosjektleveranser, og hver leveranse kan bestå av flere produkter. 

Prosjekttilnærming beskriver hvordan prosjektet skal gå frem for å løse oppgaven. Den kan for eksempel beskrive om prosjektet skal utvikle løsningen selv, anskaffe den, bruke smidige metoder, samarbeide med leverandører eller kombinere flere arbeidsformer. 

Risiko handler om usikre hendelser som kan påvirke prosjektets mål, produkter, leveranser, kostnader, tid, kvalitet, omfang, nyttevirkninger eller bærekraft. Risiko kan være negativ, men usikkerhet kan også innebære muligheter.  

Risikostrategien beskriver hvordan prosjektet skal arbeide med risiko. Den bør beskrive formål, prosedyrer, roller, ansvar, risikotoleranser, verktøy og krav til rapportering. 

I denne konteksten er en sak en hendelse som kan påvirke prosjektet og som krever oppmerksomhet fra prosjektledelsen. Saker kan for eksempel være endringsanmodninger, avvik fra krav eller akseptansekriterier, bekymringer, problemer eller nye muligheter. Saker bør vurderes og håndteres på en strukturert måte. 

En saksrapport beskriver konsekvenser og anbefalte tiltak for en formell sak. Saksrapporten brukes når en sak må behandles og besluttes på et høyere styringsnivå. 

En samfunnsøkonomisk analyse vurderer hvilke nyttevirkninger og kostnader et tiltak kan gi for samfunnet. Analysen brukes som grunnlag for å vurdere om et tiltak er lønnsomt og riktig å gjennomføre. 

Sluttrapporten gis fra prosjektleder til prosjektstyret og bekrefter overlevering av produkter, vurderer prosjektets sluttresultat og sammenligner gjennomføringen med styringsdokumentasjonen.

Statusrapporten er en tidsdrevet rapport fra prosjektleder til prosjektstyret eller prosjekteier. Den beskriver fremdriften i en fase og rapporteres på faste, avtalte tidspunkter. 

Strategi for endringsledelse beskriver hva som må være på plass for at prosjektet skal nå målene sine, og hvordan organisasjonen skal bevege seg fra dagens situasjon til ønsket fremtidig situasjon. Den kan også beskrive eventuelle mellomsteg underveis. 

Styringsdokumentet samler den styringsinformasjonen som utgjør avtalen mellom prosjekteier og prosjektleder. Det beskriver blant annet mål, rammer, organisering, planer, risiko, nyttevirkninger og styringsopplegg. Styringsdokumentet med vedlegg danner grunnlag for oppfølging og vurdering av måloppnåelse. Dokumentet er en del av den samlede styringsdokumentasjonen. 

Styringsdokumentasjon er en av tre former for dokumentasjon i Prosjektveiviseren, og er en samlet betegnelse for dokumentene som brukes til å styre prosjektet og ta beslutninger gjennom hele prosjektets livsløp og gir oversikt over de sentrale forholdene i prosjektet. Den skal være retningsgivende og avklarende for prosjekteier, prosjektleder, prosjektteamet og relevante interessenter. Styringsdokumentasjonen utvikles gjennom prosjektløpet og danner grunnlag for styring, beslutninger og oppfølging.   

Styringsdokumentasjonen består oftest av følgende dokumenter: 

• mandat for konseptfasen
• prosjektbegrunnelse
• prosjektforslag
• interessentanalyse
• styringsdokument
• plan for nyttestyring
• faseplaner
• sluttrapport
• konseptevalueringsrapport

Et styringsparameter er et område prosjektet skal styres og følges opp mot. For hvert styringsparameter bør det angis toleranser som viser hvor mye prosjektet kan avvike fra planen før saken må vurderes eller løftes. Prosjektveiviseren bruker syv styringsparametere: nyttevirkninger, kostnader, tid, kvalitet, omfang, bærekraft og risiko. 

En testplan er en systematisk beskrivelse av hvordan testprosesser skal gjennomføres i et prosjekt.

En usikkerhetsanalyse er en beskrivelse av usikkerhetene som finnes i et prosjekt. En usikkerhetsanalyse er svært lik en risikoanalyse, men tar også med positive hendelser som kan oppstå i prosjektet.

I denne konteksten er uformelle saker mindre eller dagligdagse utfordringer som kan løses innenfor prosjektleders myndighet. De krever ikke formell eskalering eller beslutning på høyere styringsnivå. Dette er saker som ikke går utenfor de satte akseptansekriteriene (toleransene) for prosjektleder opp mot styringsparameterne.

Virksomhetsstyring er ledelsens arbeid med å sikre at virksomheten har gode systemer for styring, kontroll og oppfølging. Det handler blant annet om mål, ressurser, prioriteringer, internkontroll, risiko og virksomhetens omdømme. 

En av tre former for dokumentasjon i Prosjektveiviseren, som beskriver dokumentasjonen som brukes til å operativt lede, følge opp og lære av prosjektet. Dette kan være logger, registre, rapporter, beslutningsgrunnlag, strategier, notater og andre arbeidsprodukter som gjør prosjektet styrbart og etterprøvbart. I PRINCE2 og tidligere versjoner av Prosjektveiviseren omtales mye av dette som ledelsesprodukter.    

Øvrig prosjektdokumentasjon kan eksempelvis være noen av disse dokumentene

• Erfaringslogg
• daglig logg, interessentregister
• statusrapport
• saksrapport
• beslutningslogg
• risiko- og usikkerhetsvurderinger
• kommunikasjonsstrategi
• kvalitetsstrategi
• kontraktstrategi
• bærekraftstrategi
• data- og digitaliseringsstrategi
• strategi for endringsledelse
• dokumentasjon fra møter, avklaringer og beslutninger

Ikke alle prosjekter trenger alle disse dokumentene. Omfanget må tilpasses prosjektets behov 

En brukerhistorie er en kort beskrivelse av et behov og ønsket funksjonalitet sett fra brukerens perspektiv. Den beskriver hvem brukeren er, hva brukeren ønsker å få til, og hvilken verdi det gir. 

Den kan formuleres slik: Som [rolle] ønsker jeg [behov], slik at [verdi]. 

Et eksempel kan være: Som saksbehandler ønsker jeg å få varsel når en sak mangler dokumentasjon, slik at jeg kan følge opp saken før fristen går ut. 

Brukerhistorier hjelper brukere, produkteier og utviklingsteam med å få en felles forståelse av hva som skal løses. Det er behovet som skal beskrives, ikke detaljer om hvordan løsningen skal bygges.  

En metode som bruker tall som øker i større sprang, for eksempel 1, 2, 3, 5, 8 og 13. Tallene viser relativ størrelse og kompleksitet (ikke arbeidstimer); Jo større oppgaven er, jo mer usikkerhet er det vanligvis knyttet til den. Skalaen passer når teamet har mer kunnskap om oppgavene og trenger et mer nyansert estimat enn S, M, L og XL, og hjelper teamet med å vurdere hvor mye arbeid som realistisk kan tas inn i en tidsboks.  

Et eksempel kan være at teamet vurderer en enkel justering som 1, en mindre endring i et skjema som 3, en ny funksjon som 5, og en krevende integrasjon som 13. En oppgave som får et høyt tall, bør ofte undersøkes nærmere eller deles opp før teamet starter arbeidet. 

Fremdriftsdiagrammer brukes for å vise hvordan arbeidet utvikler seg over tid. Ved å sammenligne levert arbeid opp mot estimerte leveranser kan teamet få oversikt over faktisk fremdrift, og lettere prioritere hva de rekker innen tidsboksen det jobbes innenfor. Fremdriftsdiagrammer kan inngå i en teamtavle eller et prosjektdashboard sammen med produktkø, status for iterasjonen, risikoer og saker. Da får teamet og prosjektleder en samlet oversikt over fremdrift og forhold som kan påvirke leveransen

Fremdriftsdiagrammer bør ikke bare vise aktivitet. De bør først og fremst vise ferdige leveranser og gjenstående arbeid. Da blir det lettere å styre etter faktisk fremdrift, ikke bare etter hvor mye tid som er brukt. Et enkelt fremdriftsdiagram kan vise hvor mange oppgaver som gjenstår i en tidsboks. Hvis teamet starter med 20 oppgaver og har 8 igjen halvveis, gir det et raskt bilde av om arbeidet går som planlagt. 

Et vanlig eksempel er et “burndown”-diagram. Det viser hvordan gjenstående arbeid reduseres gjennom en sprint eller iterasjon. Hvis kurven ikke går nedover som forventet, kan teamet bruke diagrammet til å prioritere på nytt, redusere omfanget eller løfte en sak hvis avviket påvirker tid, kostnad, nytte eller risiko. 

En iterasjon er en avgrenset arbeidsrunde der teamet planlegger, utvikler og ferdigstiller en del av løsningen. Iterasjonen har en tydelig start og slutt, og målet er å lære noe nytt eller levere noe konkret innenfor den avtalte tidsrammen. Et inkrement er resultatet av en iterasjon; en ferdig del av løsningen som kan vises frem, testes med brukere eller tas i bruk dersom den er klar for det. Hvert inkrement bygger videre på det som allerede er laget, slik at løsningen vokser steg for steg 

Iterasjon er altså selve arbeidsrunden, mens inkrementet er det man sitter igjen med når arbeidsrunden er ferdig. Når prosjektet jobber iterativt og inkrementelt vil det si at løsningen utvikles gjennom flere korte arbeidsrunder, der hver runde gir ny læring og en ny eller forbedret del av løsningen. Dette reduserer risikoen for å utvikle mye på én gang uten å vite om løsningen faktisk treffer behovet. 

Kanban er en smidig metode som brukes for å visualisere arbeid, begrense pågående arbeid og skape bedre flyt. Arbeidet vises ofte på en tavle der oppgaver flyttes mellom ulike steg, for eksempel «klar», «under arbeid», «test» og «ferdig». 

En tavle for flyt, risiko og saker gir teamet en felles visuell oversikt over arbeidet. Tavlen kan vise hva som er planlagt, hva som pågår, hva som er ferdig, hva som blokkerer fremdrift, og hvilke risikoer eller saker teamet må følge opp.

Tavlen kan brukes i daglige møter, statusmøter og andre korte avklaringer. Det gjør det enklere å se hvor arbeidet stopper opp, hvilke oppgaver som har ventet lenge, og hvilke forhold som kan påvirke tid, kvalitet, omfang, nytte eller risiko. For et smidig team kan tavlen vise produktkø, arbeid i inneværende iterasjon, fremdrift, blokkeringer og risikoer. For prosjektleder og prosjekteier kan en mer overordnet tavle eller dashboard vise status for leveranser, fremdriftsdiagrammer, risikoer, saker og behov for beslutninger.

Tavlen skal ikke erstatte prosjektstyring, rapportering eller beslutningspunkter. Den skal gi bedre oversikt og gjøre det lettere å oppdage avvik tidlig, prioritere riktig og løfte saker når de påvirker prosjektets rammer eller forventede nytte.

Et konseptbevis er en tidlig test eller dokumentert vurdering som skal sannsynliggjøre at et konsept er realistisk, gjennomførbart og verdt å gå videre med. Konseptbevis brukes særlig i konseptfasen, og kan eksempelvis bygge på prototyper, MVP eller andre analyser for å synliggjøre at prosjektet lykkes, før virksomheten beslutter om arbeidet skal planlegges og gjennomføres videre.

Konseptbevis brukes for å gi bedre beslutningsgrunnlag, ikke først og fremst for å utvikle en løsning (slik som prototype og MVP). Det brukes for å teste om konseptvalget er realistisk, svarer på brukerbehov, lar seg gjennomføre innenfor gitte rammer og forutsetninger.

Lean startup er en hypotesedrevet metode der teamet tester antakelser raskt og lærer underveis. Målet er å lage minst mulig for å få mest mulig læring, slik at prosjektet kan justere retning før det brukes mye tid og ressurser på full utvikling. 

Et minste levedyktig produkt (Minimum Viable Product, eller MVP), er den minste versjonen av en løsning eller et produkt som gir nok innsikt og reell læring fra brukere eller andre målgrupper. En MVP trenger ikke å være en ferdig og komplett løsning, men den skal ha nok innhold og være av en kvalitet til at den kan prøves ut i en realistisk sammenheng Den skal hjelpe prosjektet med å teste om de er på rett vei, og om løsningen dekker et reelt brukerbehov og faktisk bidrar til nyttevirkninger. En MVP brukes for å redusere risiko tidlig ved å gi prosjektet tilbakemeldinger før det brukes mye tid og ressurser på å utvikle en løsning som kanskje ikke gir ønskede nyttevirkninger. 

En MVP skiller seg fra en prototype ved at den i større grad er en første fungerende versjon av løsningen, ikke bare en demonstrasjon av hvordan løsningen kan bli.

Planleggingspoker er en metode der teamet estimerer sammen. Hver deltaker velger et estimat, for eksempel fra Fibonacci-skalaen, uten å vise det til de andre. Deretter viser alle estimatet samtidig. Hvis estimatene spriker, diskuterer teamet hvorfor de vurderer oppgaven ulikt, før de estimerer på nytt.  

Planleggingspoker passer når teamet trenger en felles vurdering av oppgaver, særlig når det er usikkerhet eller ulike oppfatninger om hvor krevende en oppgave er. Verdien ligger ikke bare i tallet teamet ender på, men i samtalen som oppstår når estimatene spriker. 

Et eksempel kan være at noen i teamet vurderer en oppgave til 3, mens andre vurderer den til 8. De som har gitt høyt estimat kan ha sett en risiko eller avhengighet de andre ikke har tenkt på. Etter diskusjonen kan teamet enten bli enige om et estimat, dele opp oppgaven eller hente mer informasjon før den prioriteres. 

En produktkø er en prioritert oversikt over behov, funksjoner og leveranser som prosjektet vurderer å utvikle. Køen vedlikeholdes kontinuerlig og oppdateres når prosjektet lærer mer. Produkteier og eventuelt produktsjef prioriterer innholdet, mens teamet vurderer hva som er mulig å levere innenfor rammene. 

En produktvisjon beskriver hva produktet eller løsningen skal bidra til, og hvilket problem det skal løse. Den bør beskrive ønsket verdi og retning, ikke en detaljert løsning. 

En prototype er en forenklet fremstilling av hvordan en løsning kan se ut, fungere eller oppleves. Den kan være en skisse, en klikkbar modell, en enkel teknisk demonstrasjon eller en annen tidlig versjon som ikke er ment å tas i bruk som ferdig løsning.

Formålet med en prototype er å teste antakelser og få tilbakemeldinger før prosjektet bruker mye tid og ressurser på utvikling. En prototype brukes særlig for å undersøke brukerforståelse, arbeidsflyt, utforming, funksjonalitet eller tekniske valg. Den gir læring, men er ikke nødvendigvis en fungerende eller bruksklar del av løsningen.

En release er den eller de delleveransene som er ferdige og gjort tilgjengelig for brukerne. Å fortløpende tilgjengeliggjøre nye deler for brukeren, ofte omtalt som hyppig release, muliggjør at man tidligere oppdager feil eller mangler, og raskere kan gjøre korrigeringer. 

En releaseplan viser hvordan leveranser er tenkt delt opp og levert fremover i tid. Planen bør oppdateres når behov eller prioriteringer endres.  

Relativ estimering betyr at teamet vurderer hvor stor eller krevende en oppgave er sammenlignet med andre oppgaver, i stedet for å beregne nøyaktig tidsbruk. Metoden passer godt i smidig arbeid, der teamet ofte lærer mer om kompleksitet og hastighet etter hvert som det leverer. 

Retrospektiv er en metode der teamet ser tilbake på arbeidet og arbeidsmetode for å lære og forbedre seg. Teamet vurderer hva som fungerte godt, hva som bør forbedres, og hvilke tiltak som kan gjøre neste arbeidsrunde bedre. 

Scrum er et smidig rammeverk for iterativ og inkrementell utvikling. Teamet planlegger og leverer et inkrement i en sprint, får tilbakemelding og bruker læringen til å justere videre arbeid. 

En sprint er en fast tidsboks i Scrum. I løpet av sprinten prioriterer, planlegger og leverer teamet et inkrement eller en del av en større løsning. En sprint varer ofte to, tre eller fire uker. 

Sprintkøen består av elementer fra produktkøen som er planlagt utviklet i den aktuelle sprinten. 

Team Topologies er en metode for å fordele ansvar mellom team i større utviklingsoppgaver. Den kan brukes når flere team må samarbeide om samme produkt eller løsning, og det er behov for tydeligere ansvarsdeling. 

En testplan beskriver hvordan testing skal gjennomføres i prosjektet. Den kan beskrive testtyper, ansvar, testmiljøer, testdata, tidsplaner og hvordan testresultater skal følges opp. 

En tidsboks er en fast tidsramme for en aktivitet eller en arbeidsperiode. Det kan for eksempel være et kort daglig møte eller en iterasjon på to uker. Når tidsboksen er satt, skal den ikke forlenges for å få plass til mer arbeid. Teamet må i stedet prioritere hva som er viktigst å bli ferdig med innenfor rammen.

Tjenestedesign og design thinking brukes for å forstå brukerbehov, utforske muligheter, teste konsepter og utvikle løsninger som treffer faktiske behov. Metodene brukes ofte i tidlig fase og i arbeid med tjenester og brukeropplevelser. 

En enkel måte å estimere på, der teamet vurderer om en oppgave er liten, middels, stor eller ekstra stor (slik som T-skjortestørrelser fra S, M, L eller XL). Metoden passer godt tidlig i arbeidet når teamet ikke vet nok til å gi mer presise estimater, og kan hjelpe teamet med å se hvilke oppgaver som bør deles opp før de planlegges mer detaljert. 

Et eksempel kan være at en liten tekstendring vurderes som S, et nytt felt i et skjema vurderes som M, en ny søkefunksjon vurderes som L, og en større integrasjon mot et annet system vurderes som XL. Hvis en oppgave blir vurdert som XL, kan det være lurt å dele den opp i mindre deler.