Så skapar du ett bra Jira-arbetsflöde

Design av Jira-workflow: hela processen på ett ögonblick

Tack vare min yrkesbakgrund som processledare lägger jag särskild vikt vid lättlästa workflows. Det finns tre sätt att visualisera ett workflow för att göra det mer lättläst, och dem går vi igenom nedan.

Händelsestyrd processkedja (EPC)

Vi bygger förstås inte händelsestyrda processkedjor i Jira, men denna typ av visualisering är en av de vanligaste.

Processens ideala flöde visas uppifrån och ned. Viktiga eller avvikande statusar placeras till vänster eller höger om processflödet.

Business Process Modeling Notation (BPMN)

I den här versionen bygger vi processer som liknar EPK-diagram, men de läses från vänster till höger. Enligt min mening är de enklare att förstå eftersom de är lättare att överföra till Kanban- eller Scrum-tavlor, både praktiskt och mentalt.

Vattenfallsmodellen

Med vattenfallsmodellen organiserar vi statusar i stegvis ordning. Vi börjar längst upp till vänster och arbetar oss nedåt till längst ned till höger. Denna form av visualisering har en särskild fördel eftersom övergångar kan separeras visuellt och återflöden kan göras tydligt igenkännbara.

Den kan ses som en hybrid av de båda diagram som nämns ovan, eftersom den kombinerar fördelarna med händelsestyrda processkedjor och BPMN-diagram när det gäller läsbarhet, särskilt för mer komplexa workflows.

Workflow- och verksamhetsregler

Jag vill betona att jag inte är intresserad av att påtvinga regler. Jag ser snarare värdet i tydligt definierade villkor som vägleder varje användare och administratör.

Ansvarsfriskrivning: Det här stycket är den mest kontroversiella punkten i hela Atlassian-communityt. Jag ser fram emot din feedback och inbjudningar till konferenser och poddar!

Statusnamn: enkla, globala och återanvändbara

En avgörande faktor för ett bra Jira-workflow är att namnge de enskilda statusarna optimalt. Men hur hittar du rätt namn? Det hjälper att komma ihåg målet – att beskriva ett ärendes tillstånd (inte dess status). Namnet bör vara så enkelt och abstrakt som möjligt.

Namngivning av statusar är ett vanligt diskussionsämne bland företag och communities. Här är några tips för att skapa en tydlig och lättbegriplig struktur för statusnamn:

Statusar som består av ett ord, exempelvis Open, Closed eller Waiting, beskriver ärenden som ingen arbetar med. Statusar där en eller flera personer aktivt arbetar kallas In Progress, Review eller Test.

En annan viktig aspekt vid namngivning av statusar är återanvändbarhet. Statusar kan och bör vara individuella, men undvik att definiera dem alltför detaljerat. Tänk: ”så mycket som behövs, så lite som möjligt”.

Alla projekt med olika testfaser har statusen In Testing. Denna status förklarar inte vilket test som avses, vare sig det är E2E (End-to-End) eller UAT (User Acceptance Test). Och det är inte nödvändigtvis viktigt att veta, särskilt när fler än en typ av testning pågår. Det viktiga är att den globala klassificeringen fungerar för alla aktiviteter och att statusen är definierad.

Dessutom bör samma eller liknande statusar i olika kategorier undvikas. Det skapar struktur och hjälper dig att medvetet flytta ett ärende till nästa status. För att stödja ett ärendes styrda workflow är det viktigt att tilldela det rätt kategorier.

Så snart en status i statuskategorin In Progress har nåtts måste alla efterföljande statusar också tillhöra den. Det är viktigt att skilja mellan åtgärder som kan påverkas och sådana som inte kan påverkas.

Om du väntar länge på en extern tjänsteleverantör bör du fråga dig: ”Kan jag fortfarande påverka detta själv, eller ska jag stänga ärendet?” Därefter behöver du fatta ett medvetet beslut.

Statusregler: När behöver jag en status?

När behöver jag en ny status? Har du någon gång ställt dig den frågan? Kanske på möten där verksamhetsavdelningen efterfrågar den ena statusen efter den andra? Har du också önskat att du hade argument både för och emot? För många år sedan ställde jag mig själv just dessa frågor. Jag undersökte ämnet, pratade med olika personer och läste artiklar, vilket resulterade i följande lista med frågor:

1. Behöver personer få ett meddelande? 2. Får endast vissa personer göra en övergång till en status? 3. Förändras ansvaret från den föregående till den nya statusen? 4. Måste personer kunna filtrera på denna status? 5. Måste personer kunna rapportera denna status, till exempel tid i status?

Om du kan svara JA på alla dessa frågor är väntköer (lager) ytterligare ett ämne som behöver hanteras separat.

Väntköer

För mig är väntköer preliminära statusar där inget arbete utförs. Här ligger processen och väntar på att dras vidare till nästa status. Enligt min mening är en dålig workflow-design en av anledningarna till att dessa statusar används, ofta på grund av push- och pull-principen.

Låt oss titta på följande exempel:

I det här workflowet finns en preliminär status. Den visar att ett ärende är tillgängligt för nästa arbetssteg.

Om vi tar bort dessa statusar och utökar workflowet med en postfunktion som säkerställer att den ansvariga återställs vid en statusövergång, till exempel från Pågår till Under granskning , får vi samma resultat.

Kanban-tavlans kolumn visar då tilldelade och otilldelade ärenden. En medarbetare kan därmed AKTIVT TA ett ärende (PULL). På så sätt sparar vi minst tre statusar.

Tips: Försök undvika väntköer och använd workflow-funktioner för att behålla push- och pull-principen.

Start- och slutstatus

Enligt min mening finns det ingen bra anledning till att workflows i en organisation ska ha olika start- och slutstatusar. För att hålla det enkelt bör varje workflow börja med statusen Öppen och avslutas med statusen Stängd.

Den här enkla regeln skapar tydlighet för både administratörer och användare som vill ha nya workflows eller får arbeta med befintliga.

Status kontra lösning

En annan utmaning är att blanda ihop statusar och lösningar. Som nämnts bör den sista statusen alltid vara Stängd. En status som Klar, Utfasad eller Återkallad finns inte, eftersom det inte är en status utan information, det vill säga lösningen.

Tips: Säkerställ att rätt information (lösning) anges när ärendet stängs.

Övergångar kontra information

Det måste finnas en övergång för att ett ärende ska kunna flyttas mellan två statusar. En övergång är en enkelriktad koppling, så om ett ärende behöver flyttas fram och tillbaka mellan två statusar måste två övergångar skapas.

I mjukvaruutvecklingsteam ser man ofta statusar som Prioritering, förberedelse och förfining. De kan vara nödvändiga och rimliga i större organisationer eller på planeringstavlor. Men du bör fråga dig vad som faktiskt händer i dessa statusar.

Ofta fyller vi i fält som Prioritet eller Story points i slutet av teammöten. Det finns betydligt enklare och bättre lösningar, till exempel att använda sprintar eller appar som Structure. Statusar som de ovan nämnda ökar workflowets komplexitet och ger mindre nytta för teamet än för produkt- eller projektledaren.

Alla övergångar

Jag är kluven inför de så kallade Alla övergångar. En process är ett riktat flöde av aktiviteter, men Alla övergångar gör det möjligt att flytta ärenden fram och tillbaka mellan statusar. Ärenden kan till exempel flyttas från flera statusar till Vilande. I sådana fall kan en riktad process inte längre garanteras. Därför är det ännu viktigare att varje statusändring är ett medvetet beslut.

Eftersom en övergång explicit eller implicit tillför mer information till ett ärende skiljer den sig från tidigare statusar. Alla övergångar kan därför skapa förvirring om ärenden flyttas för snabbt och vårdslöst. Jag skulle till viss del hävda att de motverkar disciplin. När de används på rätt sätt och hanteras medvetet kan de påskynda och förenkla ett workflow.

Det finns många delar som utgör ett bra Jira-workflow

En lättläst workflow-design med olika statusfärger och tydligt strukturerade övergångar utgör grunden. Dessutom förbättrar generella workflow- och verksamhetsregler för statusnamn samt en tydlig definition av start- och slutstatusar workflowet.

Att varje statusändring ska vara ett medvetet beslut hjälper till att följa de definierade statusreglerna. På så sätt kan väntköer undvikas och Alla övergångar användas målinriktat. Målet bör alltid vara en riktad process.

Jag vill avsluta med att återigen betona att det finns många sätt att skapa ett bra Jira-workflow. Därför handlar den här artikeln inte om att fastställa och påtvinga regler, utan om möjligheterna.