Jira, Azure DevOps og backlog‑data: sikring og analyse

Forside · Gennemgået oktober 2026 · Af John Nielsen

I et agilt projekt er backloggen projektets hukommelse: hvad der var planlagt, hvad der blev tilføjet undervejs, hvad der blev estimeret, og hvad der blev leveret i hver sprint. I en tvist kan backlog-data vise, hvordan omfanget udviklede sig, og hvornår det skete. De rapporter, værktøjerne viser på skærmen, er dog beregnet ud fra den nuværende opsætning og kan ikke uden videre bruges som bevis. Det er de underliggende ændringer, der skal sikres og analyseres.

Hvordan ændringshistorikken for den enkelte sag trækkes ud af Jira og andre ticket-systemer, er beskrevet i ticket-systemer: ændringshistorik. Denne artikel ser på backloggen som helhed: sprints, estimater og omfang.

Hvad backloggen indeholder

Work items eller sager · Krav, user stories, fejl og opgaver med status, ansvarlig og relationer
Estimater · Story points eller timer, og hvordan de ændrede sig
Sprint- eller iterationsfelt · Hvilken sprint en opgave var planlagt i, og om den blev flyttet
Prioritet og rækkefølge · Hvad der blev prioriteret, og hvem der ændrede det
Boardets opsætning · Kolonner, statusser og filtre, som rapporterne bygger på
Kommentarer og vedhæftninger · Drøftelser om omfang, accept og afvisning

Jira

Jira Software har sprints som egne objekter med start- og slutdato og et sprintfelt på hver sag. Agile-API’et giver adgang til sprints og deres sager, fx GET /rest/agile/1.0/sprint/{sprintId} og GET /rest/agile/1.0/sprint/{sprintId}/issue. Sagens ændringslog viser, hvornår sprintfeltet, estimatet og status blev ændret, og af hvem.

Sprintrapporten markerer sager, der blev tilføjet efter sprintens start, med en stjerne, og et estimat, der blev ændret under sprinten, vises med to tal og en pil. Atlassian oplyser, at rapporten kun gælder Scrum-boards, kun medtager sager, der matcher boardets gemte filter, og bygger To Do og Done på boardets kolonneopsætning. Ændres filteret eller kolonnerne senere, ændres rapporten for gamle sprints også. Rapporten er derfor en visning, ikke en registrering.

Azure DevOps

I Azure DevOps har hvert work item en række revisioner, der kan hentes via REST-API’et med GET https://dev.azure.com/{organization}/{project}/_apis/wit/workItems/{id}/revisions. Hver revision indeholder felternes værdier på det tidspunkt, herunder System.IterationPath for sprinten, System.State, System.ChangedBy og System.ChangedDate, samt estimatfelter afhængigt af proces.

Analytics-tjenesten giver OData-adgang til historikken. Entiteten WorkItemRevisions indeholder alle revisioner, men ifølge Microsoft ikke slettede work items. WorkItemSnapshot giver tilstanden for hvert work item for hver dag og bruges til burndown- og trendrapporter. Den er praktisk til analyse, men det er revisionerne, der er primærkilden.

Sikring

Hent alle work items eller sager i projektet via API med fuld ændringshistorik, ikke kun dem, der er åbne nu.
Hent sprints eller iterationer med navne, start- og slutdatoer, og registrér, om datoerne er ændret.
Sikr boardets opsætning: filtre, kolonner, statusser og arbejdsgange. Uden den kan rapporterne ikke genskabes.
Hent brugerlisten med konto-id og visningsnavn på sikringstidspunktet.
Tag skærmbilleder eller eksporter af sprintrapporterne som de så ud ved sikringen, som supplement og ikke som erstatning for rådata.
Sikr slettede elementer, hvor værktøjet har papirkurv, og notér, hvad der ikke kan hentes.
Hash alle eksporter, og registrér værktøj, API-version, konto og tidspunkt.

Hvis projektet er i krise, bør backloggen indgå i en samlet plan sammen med repositorier og byggedata. Se bevaringsplan for et IT-projekt i krise.

Analyser, der går igen

Omfangsændringer. Ud fra historikken kan det opgøres, hvor mange opgaver og point der blev tilføjet, fjernet eller ændret i hver periode, og af hvem. Det er grundlaget for at vurdere påstande om, at kunden løbende udvidede omfanget, eller at leverandøren fjernede opgaver for at nå en milepæl.

Flytning mellem sprints. En opgave, der er flyttet fra sprint til sprint, viser, at den gentagne gange ikke blev færdig. Mønstret kan vise, hvor projektet sad fast.

Estimater over tid. Ændringer i estimater kan pege på, at opgaver var dårligt beskrevet, eller at omfanget voksede inden for den enkelte opgave.

Status mod levering. Status “færdig” i backloggen kan holdes op mod commits, byg og udrulninger. En opgave lukket uden tilknyttet kode eller udrulning bør undersøges nærmere. Koblingen mellem krav, kode og test er beskrevet i kravsporbarhed.

Velocity. Leveret mængde pr. sprint kan vise et forløb, men story points er relative, teamets egne og kan ikke sammenlignes på tværs af teams eller omregnes direkte til timer. Sammenhæng med fakturerede timer er en særskilt analyse, se timeregistrering mod commits og tickets.

Faldgruber

Automatisering. Regler i værktøjet kan ændre felter, flytte sager og lukke dem. Ændringen står da på en automatiseringskonto eller på den bruger, der ejer reglen. Sikr reglerne og deres historik.
Masseredigering. Mange ændringer med samme tidspunkt skyldes ofte én handling, fx når en sprint afsluttes og åbne sager flyttes til næste. Det er ikke mange selvstændige beslutninger.
Omdøbte statusser og felter. Historikken kan vise gamle navne, der ikke længere findes i opsætningen.
Sprintens startdato. Hvis startdatoen er sat tidligere end det tidspunkt, sprinten reelt blev startet, kan sager vises som tilføjet efter start, selvom de var med fra begyndelsen.
Flere boards på samme sager. Samme sag kan indgå i flere boards med forskellige filtre og dermed forskellige rapporter.
Tidszoner. API’erne returnerer typisk tidspunkter i UTC, mens skærmen viser brugerens tidszone.

Præsentation

Resultaterne formidles bedst som tidsserier og tabeller, der kan føres tilbage til rådata: antal opgaver og point i backloggen pr. uge, tilføjelser og fjernelser pr. sprint, og en liste over de konkrete ændringer bag hvert tal. Egne beregninger bør bygge på de sikrede revisioner og ikke på værktøjets rapporter, og metoden for optællingen skal beskrives, fx om underopgaver tælles med, og hvordan en sag, der er flyttet frem og tilbage, opgøres.

Hvad backlog-data kan og ikke kan bevise

Ændringshistorikken kan med stor sikkerhed vise, hvad der stod i backloggen på et bestemt tidspunkt, hvem der ændrede det, og hvordan omfanget og planen udviklede sig. Den kan ikke vise, om et ønske var en ændring af aftalen eller en præcisering af et eksisterende krav. Det kræver, at backloggen holdes op mod kontrakten og kravene. Den viser heller ikke, hvad der blev sagt på møder, der ikke er skrevet ned. Den juridiske side af ticket-data som bevis er beskrevet på digital-bevissikring.dk, og virksomhedens egne projektværktøjer på bevissikring-digitalt.dk.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Læs også: Testdata, testrapporter og testmiljøer som bevis i IT-tvister · Git-historik i projekttvister: hvem leverede hvad og hvornår

→ Uvildig IT-sagkyndig med forensic-baggrund · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik