Definition av klart: Vad det är och hur du använder den

Här är de viktigaste egenskaperna hos en effektiv definition av klart:

• Transparens: Alla i teamet och viktiga intressenter kan se den, läsa den och hänvisa till den när som helst.
• Mätbar: Varje kriterium är binärt. Arbetet uppfyller antingen kriteriet eller inte, men de tröskelvärden du väljer för kvantitativa kriterier kräver noggrant övervägande. Ett mål på 80 % kodtäckning är binärt när det gäller efterlevnad, men valet av 80 % framför 70 % eller 90 % är ett bedömningsbeslut som du bör fatta medvetet
• Universellt förstådd: Varje medlem i Scrum-teamet måste kunna tolka varje punkt på samma sätt.
• Konsekvent tillämpad: Samma checklista måste tillämpas på varje leverans och varje produktbackloggobjekt. 
• Uppnåelig inom en sprint: Kriterierna bör vara tillräckligt realistiska för att teamet ska kunna uppfylla dem under en enda sprint eller iteration.

I programvaruutvecklingsprojekt är det vanligtvis utvecklarna som äger definitionen av klart, eftersom det är de som ansvarar för att följa den. Produktägaren och Scrum mastern bör dock bidra.

Om din organisation har egna standarder för definitionen av klart måste varje Scrum-team följa dem som en miniminivå. Team kan alltid lägga till striktare kriterier, men de kan inte gå under organisationens lägstanivå.

Varför definitionen av klart är viktig

En tydlig definition av klart är viktig eftersom den förhindrar att delvis slutfört arbete slinker igenom och ger en gemensam kvalitetsstandard.

Här är några ytterligare skäl till att en gemensam definition av klart är viktig:

• Fungerar som en inbyggd kvalitetsgrind: Varje punkt måste uppfylla samma krav innan den kan anses vara klar. Det hindrar halvfärdigt arbete från att smyga sig in i ditt produktinkrement och samlas som teknisk skuld.
• Eliminerar tvetydighet: När teamet delar en definition hamnar ni inte i situationer där motstridiga definitioner påverkar arbetets hastighet eller kvalitet. En gemensam definition av klart innebär färre konflikter, färre överraskningar och tydligare demonstrationer.
• Förbättrar prognoserna: När klart betyder samma sak varje sprint kan du prognostisera arbetstakten med tillförsikt och planera lanseringar utan att lägga till marginaler i uppskattningarna för att ta hänsyn till omarbete.
• Bygger förtroende hos intressenter: När produktägare, ledning och externa intressenter kan se att teamet upprätthåller en tydlig kvalitetsstandard litar de på era resultat. 
• Förhindrar integrationskaos: Om ni arbetar på ett sätt som kräver att teamet integrerar sitt arbete i ett gemensamt inkrement är en gemensam förståelse av definitionen av klart grunden för konsekventa inkrement som kan lanseras. 

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Create Free Account

Have an account? Log In

Så skapar du en definition av klart

Här är de viktigaste stegen i processen för att skapa en definition av klart.

1. Granska ditt nuvarande arbetsflöde: Kartlägg varje steg som arbetet redan går igenom innan det når produktion. Prata med utvecklare, testare, designers och alla andra som arbetar med uppgiften. Du kommer att upptäcka informella kvalitetssteg som bör formaliseras.
2. Identifiera kvalitetskriterier som inte kan förhandlas bort: Bestäm vilka aktiviteter som måste genomföras för varje arbetsuppgift. Dessa omfattar vanligtvis kodgranskning, automatiserade tester, uppdatering av dokumentation och säkerhetsskanningar. Var ärlig med vad ni för närvarande hoppar över.
3. Ta fram checklistan tillsammans: Samla hela teamet och arbeta igenom den med hjälp av en whiteboard eller ett delat dokument där alla kan lägga till, ifrågasätta och förfina punkter i realtid. En definition av färdigställande som antagits genom konsensus håller mycket bättre under press än en som röstades igenom trots invändningar.
4. Validera mot organisationens standarder: Jämför utkastet med eventuella företagsövergripande kvalitetspolicyer, regulatoriska krav eller branschstandarder som produkten måste uppfylla. Om organisationen redan har en grundläggande definition av färdigställande kan du börja där och bygga vidare på den.
5. Gör den synlig: Publicera definitionen där teamet arbetar varje dag. Det kan innebära en affisch på väggen, ett fäst meddelande i Slack eller en panel i verktyget för projekthantering.
6. Åta er att följa den: En definition av färdigställande som åsidosätts när deadlines närmar sig är sämre än att inte ha någon alls, eftersom den skapar en falsk känsla av kvalitet. 

Exempel på definitioner av färdigställande

Här är några exempel på definitioner av färdigställande för olika typer av projekt:

Definition av färdigställande för programvaruutvecklingsprojekt

Programvaruprojekt står inför många olika kvalitetsrisker: buggar, säkerhetssårbarheter, försämrad prestanda och integrationsfel. Definitionen av färdigställande för ett programvaruteam behöver täcka hela vägen från kod till ett tillstånd där den kan släppas.

Den kan se ut så här:

• All kod är skriven och granskad av minst en annan utvecklare
• Enhetstesterna godkänns med den överenskomna täckningsnivån
• Integrationstesterna är godkända i CI/CD-pipelinen
• Inga öppna buggar med kritisk eller hög allvarlighetsgrad
• Den tekniska dokumentationen är uppdaterad och återspeglar ändringarna
• Koden är sammanfogad med huvudgrenen
• Produktägaren har granskat och godkänt arbetet
• Prestandariktvärdena uppfyller de överenskomna tröskelvärdena

Definition av färdigställande för marknadsföringsprojekt 

Marknadsföringsarbete omfattar ofta aspekter av efterlevnad, varumärke och mätning som skiljer sig från programvara. 

Så här kan definitionen av färdigställande se ut för ett marknadsföringsprojekt:

• Innehållet har granskats och godkänts av juristteamet
• SEO-checklistan är genomförd, inklusive metabeskrivningar, alt-text och interna länkar
• Alla tillgångar har laddats upp till CMS:et och formaterats korrekt
• Analysmätningen är konfigurerad och verifierad i testmiljön
• Den slutliga texten har korrekturlästs av en annan teammedlem
• Checklistan för kampanjlanseringen har godkänts av teamledaren

Definition av färdigställande för designprojekt 

Designteam behöver att deras definition av färdigställande överbryggar gapet mellan kreativ avsikt och teknisk överlämning. Utan en sådan kommer designer till utvecklingen i ett ofullständigt skick, med saknade specifikationer, icke-validerat responsivt beteende eller brister i tillgänglighet som upptäcks för sent.

Här är ett exempel på en definition av färdigställande för ett designprojekt:

• Designen har granskats mot tillgänglighetsstandarderna enligt WCAG 2.2
• Överlämningsfilen är förberedd i det överenskomna verktyget med alla specifikationer, tillgångar och anteckningar
• Godkännande från intressenterna har mottagits och dokumenterats
• Designsystemets komponenter har uppdaterats om nya mönster har introducerats
• Det responsiva beteendet har validerats över de överenskomna brytpunkterna

Definition av färdigställande jämfört med acceptanskriterier

Definitionen av färdigställande är er kvalitetsstandard på teamnivå, medan acceptanskriterier är funktionella krav på funktionsnivå.

Tänk på definitionen av färdigställande som den grundnivå som gäller överallt, och acceptanskriterier som unika för varje sprintbacklogg eller produktbackloggobjekt. Ett produktbackloggobjekt är färdigt när det uppfyller både sina acceptanskriterier och teamets definition av färdigställande.

Aspekt	Definition av färdigställande	Acceptanskriterier
Omfattning	Gäller för alla produktbackloggobjekt och inkrement	Specifika för en enskild användarberättelse eller ett produktbackloggobjekt
Ägarskap	Ägs av utvecklarna, med synpunkter från hela Scrum-teamet	Skrivs av eller tillsammans med produktägaren
Detaljeringsgrad	Allmänna kvalitetsstandarder för allt arbete	Detaljerade funktionella krav för en enskild arbetsuppgift
Ändringsfrekvens	Ändras sällan; uppdateras under sprintretrospektiv	Ändras med varje ny användarberättelse
Kontrollpunkt	Kontrolleras innan något objekt markeras som slutfört	Verifieras under granskning av användarberättelsen eller acceptanstestning

Vanliga fallgropar och misstag

Här är några vanliga misstag att undvika när ni skapar definitioner av färdigställande:

• Hoppa över punkter för att arbeta snabbare: Team under tidspress hoppar ofta över kriterier som säkerhetsgranskning, tillgänglighetstestning eller dokumentation. Det skapar dold teknisk skuld som senare visar sig som buggar, merarbete eller efterlevnadsproblem.
• Göra checklistan för detaljerad: En alltför detaljerad definition av färdigställande blir en byråkratisk börda. Om checklistan har 30 punkter och utvecklarna ägnar mer tid åt att kryssa i rutor än åt att bygga programvara har ni gått för långt. Var tillräckligt specifika för att checklistan ska vara meningsfull, men tillräckligt generella för att den ska förbli praktisk.
• Ändra definitionen av färdigställande för varje användarberättelse: Hela poängen med definitionen av färdigställande är konsekvens. Funktionsspecifika villkor hör hemma i acceptanskriterierna (till exempel acceptanskriterier enligt givet–när–då), inte i definitionen av färdigställande.
• Aldrig ompröva den: En definition av färdigställande bör utvecklas i takt med att era arbetssätt mognar, era verktyg förändras eller er produkt växer. Jag föreslår att ni går igenom den under retrospektiv minst en gång per kvartal och justerar den när teamet identifierar luckor eller friktion.
• Inte tillämpa den: En definition som kan åsidosättas när någon viktig person ber om det är värdelös. Scrum masterns uppgift är att skydda definitionen, även när en intressent vill lansera något som inte når upp till kraven. Om kriterierna rutinmässigt åsidosätts förlorar teamet förtroendet för standarden och slutar ta den på allvar.
• Förväxla ”färdig” med driftsatt: Definitionen av färdigställande avgör om ett inkrement kan lanseras, inte om det har lanserats. Ett produktbackloggobjekt kan vara färdigt utan att vara driftsatt. Lägg inte till ”driftsatt i produktion” i er definition av färdigställande om inte teamet verkligen ansvarar för hela lanseringsprocessen från början till slut.
• Underlåta att hänvisa till den: Många team har tekniskt sett en definition av färdigställande, men om ingen har tittat på den sedan den skapades för sex månader sedan fungerar den inte som en kvalitetsstandard.

Vad händer nu?

Bygg vidare på era agila processer och arbetssätt med praktiska verktyg, mallar och insikter från experter genom ett kostnadsfritt DPM-medlemskap, och stärk de system som hjälper team att konsekvent leverera kvalitetsarbete.