Sådan laver en acceptance testing i dine projekter
I dette indlæg skal vi kigge på hvordan du kan lave acceptance testing i dine projekter. Acceptance testing er en vigtig del af et hvert projekt, så det er vigtigt
I dette indlæg skal vi kigge på hvordan du kan lave acceptance testing i dine projekter. Acceptance testing er en vigtig del af et hvert projekt, så det er vigtigt
Der findes ikke en projektstyringsmetode, der passer til alle. For at finde den bedste måde at styre dine projekter på, kan du blive nødt til at blande og matche forskellige
I dette indlæg skal vi kigge på hvad en Product Owner har ansvar for i scrum projekter. En Product Owner er en vigtig brik i Scrum projekter, det er nemlig
I dette indlæg skal vi kigge på hvad er burndown chart er, og måske endnu vigtigere, hvordan du kan drage fordel af at bruge det i dine projekter. Et burndown
I dette indlæg skal vi kigge lidt nærmere på to af verdens mest populære projektledelsesmetoder, nemlig Scrum og Prince2. Vi skal her prøve at kigge på nogle af forskellene mellem
I dette indlæg skal vi kigge lidt mere på Scrumban, hvilket er en kombination af Scrum og Kanban projektledelsesmetoden. Det er nemlig ikke unormalt at projektledere låner lidt koncepter og
I dette indlæg skal vi kigge nærmere på hvad et Daily standup er inden for Scrum projektledelsesmetoden. Scrum er en iterativ og inkrementel ramme for softwareudvikling og er kendetegnet ved
I dette indlæg skal vi kigge på hvem der bruger scrum, og hvornår det giver mening at bruge netop denne metode. Det er ingen hemmelighed at jeg er en stor
I dette indlæg skal vi kigge nærmere på hvad et Sprint mål, eller Spring goal, er i Scrum projekter. Vi vil også se, hvordan den skal oprettes og bruges korrekt
Jeg har skrevet endnu en bog omkring projektledelse! Denne gang handler det omkring Scrum metoden. Du kan hente den nedenfor, alt hvad du skal gøre er at tilmelde til nyhedsbrevet
I dette indlæg skal vi kigge på hvad et Story Point er. Et story point er en måleenhed, der bruges til at estimere størrelsen på et stykke arbejde. De fleste
Definition of Done, forkortet DoD, henviser til de kriterier der skal være opfyldt for at en opgave kan anses for fuldendt. Definition of Done er særligt udbredt i agil udvikling
I dette indlæg vil jeg beskrive den rolle, som en Scrum Master har. Jeg begynder ved at beskrive formålet af denne rolle relativt til andre Scrum roller. Derefter definerer jeg
I denne guide giver vi dig trin-for-trin instruktioner til hvordan du kører et scrum-projekt, prioriterer og organiserer din backlog med sprints, køre scrum-møder og mere – alt sammen med Jira
Scrum organiserer arbejde i iterationer eller cyklusser af op til en kalendermåned kaldet Sprints. I dette indlæg vil jeg give en mere detaljeret beskrivelser af hvad sprints er. Derefter går
I dette indlæg vil jeg gå i dybden med koncepterne estimering og velocity. Jeg starter ud med et overblik over de vigtige roller, som estimering og velocity spiller i agil
I dette indlæg vil jeg gå i dybden med den vigtige rolle, som en product backlog spiller i et Scrum udviklingsprojekt. Jeg vil begynde med, at beskrive de forskellige typer
I dette indlæg vil jeg gå i dybden med hvordan krav i et Scrum projekt er håndteret anderledes end ved et traditionelt projekt. Jeg vil dermed beskrive rollen af user
For at forstå Scrum og de forskellige mekanismer af Scrum, så er det vigtigt at man forstår de underliggende principper, som driver og skaber disse mekanismer. Jeg vil derfor i
I dette indlæg vil jeg gå i dybden med Scrum Frameworket med fokus på hvordan du kan bruge det når du arbejder med agil projektledelse. Hvad er SCRUM? Scrum er
I dette indlæg skal vi kigge på hvad Scrum Backlog Refinement processen. Backlog refinement er en løbende proces som løber gennem hele projektets løbetid. Det er typisk projektets Product Owner
I dette indlæg skal vi kigge på hvad et Scrum board er. Et Scrum board er et vigtigt værktøj inden for Scrum, da det hjælper med at skabe et overblik
I dette indlæg skal vi kigge lidt på hvad et Scrum Review Meeting er for noget. Jeg kommer dybere ind på Sprint Review møder i mit Scrum kursus, men her
I dette indlæg skal vi kigge lidt på en sprint backlog. Jeg vil i dette indlæg ikke beskrive selve backloggen så dybdegående, da jeg allerede har beskrevet denne i et
I dette indlæg skal vi kigge på et rigtig vigtigt begreb inden for Scrum, nemlig en produkt vision. Den er en overordnet beskrivelse af hvad løsningen skal kunne, og hvad
I dette indlæg vil jeg kigge på, hvad en Scrum Master egentlig tjener, og hvad du kan forvente at tjene som Scrum Master. Da jeg lavede oversigten, viste det sig,
Scrum er uden tvivl en af de mest populære agile projektledelse metoder som bruges i nogle af de største virksomheder i verdenen, så som Google, Facebook og Amazon. Du vil
Six Sigma, Lean, PMBOK, Scrum vs. Kanban – Der er mange projektledelses jargon og metode debatter, som du måske har svært ved at finde rundt i. Der er dog kun
I dette indlæg vil jeg gerne skrive lidt omkring backlogs. Jeg vil ikke gå så dybt ned i emnet, men vil bare lige kort give en gennemgang af hvad en
I dette indlæg skal vi kigge lidt på, hvad Scrum sprints er for en størrelse, og hvordan du planlægger dine sprints. Sprints er nok noget af det mest vigtige at
I dette indlæg skal vi kigge på, hvad Epics og User stories er for en størrelse, og hvordan du bruger dem i dine projekter. Lad os sige, at du og
I dette indlæg skal vi kigge på Scrum, hvilket i dag er gået hen og blevet en af verdens mest anvendte projektledelsesmetode. Og det er der rigtig god grund til, så lad os dykke lidt ned i det i dette indlæg. Men lad os starte med at kigge på helt grundlæggende hvad Scrum er.
Scrum er en agil måde at udvikle innovative produkter og services på. Billedet nedenfor vil vise hvordan denne process ser ud. Denne agile process starter ved at man laver en product backlog, hvilket er en prioriteret liste af opgaver som skal løses for at opnå et succesrigt produkt.
Man bruger så denne prioriteret backlog til at drive projektet ud fra, det gør man ved at sikrer sig at de vigtigste opgaver altid ligger højest i backloggen. På den måde ved man altid hvilken opgave der er den næste man skal gribe, det er nemlig den opgaver som ligger øverst på den prioriterede backlog. Det smarte med denne metode er at hvis du skulle løbe tør for ressourcer i dit projekt, hvad end det er penge eller tid, så ved du altid at du har fået de vigtigste opgaver med i projektet, da du løbende har prioriteret opgaverne.
Man arbejder med opgaverne op en helt speciel måde, for man arbejder nemlig i det som hedder Sprints. Dette betyder at man arbejder i små grupper, hvor man planlægger arbejde 4-6 uger frem i tiden, og fokusere udelukkende på de opgaver. Man laver alt arbejde i sådan sprints, både design, opbygning og test af slutproduktet. Så altså alt hvad der skal til for at færdiggøre det stykke arbejde der er sat af til at skulle være færdig i dette sprint.
Man vil typisk altid have mange flere opgaver på ens product backlog end man kan nå at løse i et enkelt sprint, og man vil derfor skulle planlægge mange sprints i løbet af projektet. Men i slutningen af hver sprint afholder man det der hedder et Sprint review møde hvor man gennemgår det arbejde der er blevet lavet i dette sprint, og enten godkender eller afviser opgaverne.
Så i slutningen af hver sprint skal der altså helst være et konkret produkt, som kan leveres til kunderne og brugerne hvis de bliver godkendt. Der må helst ikke være nogle opgaver som ikke er klar til at blive leveret til brugeren. Hvis nogle opgaver er så store at man ikke kan få dem med i et normalt sprint kan man vente med at lancere dem for kunderne, og bundle 2-3 sprints sammen, men det er ikke ønskværdigt. Da det hurtigt skaber flaskehalse i projektet.
Hele Scrum-tankegangen kan spores tilbage til en artikel i Harvard Business Review i 1986 som hed “The New New Product Development Game” af Takeuchi og Nonaka. Denne artikel beskriver hvordan virksomheder som Honda, Canon og Fuji-Xerox opnåede verdensklasse resultater, mens de samtidigt kunne skalere forretningen globalt uden at rende ind i flaskehalse.
De havde nemlig fokus på at give de enkelte medarbejder ret til at tage beslutninger selv, og lod tit projektgrupper organisere sig selv, frem for at have en person til at diktere det hele. Denne artikel startede hele forløbet som senere endte ud i at blive en konkret projektledelsesmetode, nemlig den vi kender som Scrum i dag.
Scrum er ikke en forkortelse for noget. Nej, det er faktisk et ord man har lånt fra sporten rugby. Her er det nemlig en specifik måde hvorpå man starter spillet igen efter et stop undervejs. Selvom du ikke har set rugby før, så ved du nok alligevel hvad en scrum er når du ser det. Det er nemlig når de to hold står overfor hinanden, tit hånd i hånd, med deres hoved nede, og hvor de banker sammen for at se hvilket hold der kan få fat på bolden.
Takeuchi og Nonaka brugte nemlig flere metaforer omkring rugby og scrum til at beskrive deres nye måde at udvikle produkter på i den artikel. De skriver for eksempel:
“The … relay race approach to product development … may conflict with the goals of maximum speed and flexibility. Instead a holistic or “rugby” approach – where a team tries to go the distance as a unit, passing the ball back and forth – may better serve today´s competitive requirements.”
Senere i 1993 tog Jeff Sutherland og videreudviklede deres teorier ind til det vi i dag kender som Scrum metoden. Og herfra tog det fart. Mange var hurtige til at adoptere den nye metode, og den blev de efterfølgende år videreudviklet til den metode som vi kender i dag. Selvom Scrum tit er brugt til IT og Digitale projekter, så er der intet til hindring for at bruge det til alle typer projekter. Der er mange eksempler på Scrum projekter som intet har med IT eller digital projekter at gøre, og der er meget få eksempler på projekter hvor det ikke giver mening at drive dem ud fra en Scrum tankegang.
Scrum er et godt valg for virksomheder som befinder sig i det som hedder et Complex Domain , hvor der er en masse ubekendte, og hvor man løbene skal finde sin vej igennem projektet. Dette er ofte inden for brancher hvor man gerne vil være på forkant med teknologien og hele tiden innovere.
Grunden til at Scrum er god inden for disse brancher er at man ikke behøver en masse up-front planning, men at man i stedet bare kommer igang med at arbejde med metoden med det samme. Scrums fokus er derfor på at levere velfungerende, integreret, testet del-elementer af et større projekt, som både som en helhed, og for sig selv giver værdi til brugerne eller kunderne.
Scrum fungere rigtig godt til de fleste projekter, men det er mere velegnet til nogle frem for andre. Herunder vil jeg kort gennemgå nogle af de kriterier der skal til for at Scrum passer til dig projekt.
Der er nemlig ifølge Cynefin frameworket, som er lavet for at hjælpe os til at forstå den kontekst som i arbejder indenfor, siger at der er fem forskellige domæner man arbejder inden for:
Nedenfor vil jeg lige kort løbe dem alle igennem.
Når man har med komplekse problemer at gøre, så er det tit fordi at de er uforudsigelige. Det er tid sådan, at hvis der er et “rigtigt” svar på en problemstilling, så vil du først vide det når du har forsøgt at løse problemet, der er nemlig tit ikke et åbenlyst svar.
Når man arbejder inden for dette domæne arbejder man derfor tit efter “Inspect & Adapt” tankegangen, hvor man løbende holder øje med det man laver, hvordan blev del-leverancen af projektet implementeret, og så retter man til undervejs i projektet. Scrum er en rigtig god metode inden for Complex Domains, da hele denne Inspect/Adapt tankegang er bygget ind i Scrum frameworket.
Complicated problemer er dem hvor der er en best practice som er domineret af eksperter inden for feltet man arbejder i. Der kan være flere svar som kan være “det rigtige” svar på projektet, men det er typisk kun eksperterne som kan regne ud hvilke der er de rigtige løsninger til problemerne. Her er Sigma Six metoden rigtig god, men man kan også sagtens bruge Scrum metoden til sådan problemstillinger.
Når du har med simple problemstillinger, hvor alle kan se årsag og effekt af problemet og løsningen hedder det et Simple Domain. Disse er de nemme problemer, for der er altid en best practice, som man hurtigt kan Google sig frem til, eller hyre en konsulent ind til at fikse. Her kan Scrum også sagtens bruges, men der kan lige så vel bruges andre metoder.
Når man har med kaotiske problemstillinger, som man skal reagere hurtigt på, så hedder det et Chaotic Domain. Dette er tit krisesituationer hvor man går i løsningsmode med det samme, hvor der ikke er tid til sprints, planlægning eller andet. Man skal bare have slukket en ildebrand. Så her bruger man sjældent en projektledelsesmetode, her er der bare en person som skal step up, og tage ansvaret for at koordinere folk på en måde hvor man kommer hurtigt i mål.
Disorder er når du ikke ved hvilken af de andre domæner som du er en del af med dine opgaver, og det er et farligt sted at være. For så ved du ikke hvilket ben du står på, og kan ikke med sikkerhed sige hvad den rette vej frem er herfra. Så målet herfra er at finde ud af hvilket af de fire andre domæner er du i lige nu, og først derefter kan du finde ud af hvordan du skal gribe opgaven an.
Scrum er altså ikke en mirakelkur som passer til alle projekter. Men det er en super god metode når du har med Complex eller Complicated projekter, hvor fremtiden er lidt sløret. Det er tit sådan noget som IT projekter hvor det er meget brugt at bruge Scrum.
Få tilsendt denne 193 siders ebog: “Effektiv projektledelse – Din trin-for-trin guide til at drive succesfulde projekter” bare ved at tilmelde dig nyhedsbrevet.
Du vil ikke blive spammet med e-mails, og du kan afmelde dig nyhedsbrevet igen når som helst.
Står du og mangler en effektiv metode til at lede dine projekter ud fra? Så er det nu at du skal slå til! Du kan nemlig få et kursus i agil projektledelse for bare 2500,- På kurset lærer du alt hvad du skal vide for at drive effektive og succesfulde projekter ud fra den agile tankegang 😁