Doe een pre-mortem in Jira: vind releaserisico's voordat ze optreden

Een release kan in Jira klaar lijken terwijl het team nog zorgen heeft die niemand heeft opgeschreven. De implementatie is bijna af, het testen loopt en de lanceringsdatum nadert. Iemand vermoedt dat oudere klantaccounts zich anders gedragen. Een ander vreest dat ondersteuning de nieuwe bediening verkeerd zal uitleggen.

Een pre-mortem geeft die zorgen een nuttig beginpunt: stel je voor dat de release al verkeerd is gegaan en beschrijf vervolgens de oorzaak. De oefening maakt het gemakkelijker om plausibele fouten te bespreken voordat het team druk is met de gevolgen ervan.

In deze handleiding doen we een praktische pre-mortem voor een fictieve klantenportaalrelease en ordenen we de resultaten in Risk & Pre-Mortem Grid van Power Pack. Het resultaat is een korte reeks risico's met duidelijke verantwoordelijken, waarschuwingssignalen en beheersmaatregelen.

Kies een specifiek releaseresultaat

Ons team voegt e-mailvoorkeuren toe aan een klantenportaal. Klanten kunnen optionele accountmails aan- of uitzetten en blijven essentiële berichten ontvangen. Maya is verantwoordelijk voor het productresultaat, Leo implementeert de wijziging, Priya leidt het testen en Sam bereidt ondersteuning voor.

Ze kiezen het Jira-issue dat het gedeelde releaseresultaat beschrijft als plek voor hun pre-mortem. Gerelateerde implementatie- en testtickets blijven via het normale Jira-proces gekoppeld. Het gesprek bij het release-issue houden geeft mensen een duidelijke plek om erop terug te komen.

Vóór de sessie schrijft Maya een eenvoudige scopebeschrijving: beoordeel de klantervaring, het e-mailgedrag en de gereedheid van ondersteuning voor de eerste release van de voorkeursbediening. Het team kijkt naar de lancering en de eerste gebruiksweek. Die grens voorkomt dat het gesprek een beoordeling van elk mogelijk portaalprobleem wordt.

Stel je een mislukking voor voordat je oplossingen bespreekt

Begin met een concrete vraag: “Het is een week na de lancering. Klanten zijn verward, ondersteuningsverzoeken zijn toegenomen en we hebben de uitrol moeten pauzeren. Wat is er gebeurd?” De denkbeeldige uitkomst moet ongemakkelijk genoeg zijn om aan het denken te zetten, zonder te suggereren dat mislukking onvermijdelijk is.

Geef iedereen een paar stille minuten om zelfstandig mogelijke oorzaken op te schrijven. Zo kan een zorg van een tester of observatie van ondersteuning aan bod komen voordat de eerste stellige verklaring het gesprek overneemt. Vraag naar oorzaken die mensen kunnen beschrijven, in plaats van algemene uitspraken zoals “de kwaliteit was slecht”.

Deel daarna om de beurt de scenario's. Verzamel in deze eerste ronde de zorg en verduidelijk de betekenis. Bewaar discussies over de beste oplossing voor later. Een deelnemer moet een lastige mogelijkheid kunnen noemen zonder meteen een volledig herstelplan te moeten verdedigen.

• Bestaande klanten zien voorkeuren die niet overeenkomen met hun huidige e-mailinstellingen.
• De interface suggereert dat essentiële e-mails kunnen worden uitgezet.
• Ondersteuningsinstructies beschrijven bedieningselementen die vóór de release zijn veranderd.
• De voorkeur lijkt succesvol bijgewerkt, terwijl de onderliggende wijziging mislukt.

Dit zijn fictieve scenario's voor ons voorbeeld. Je eigen lijst moet komen van de mensen die het werk, de afhankelijkheden en de klantervaring begrijpen. Power Pack registreert het gesprek; het team levert het oordeel over wat er zou kunnen gebeuren.

Maak van zorgen herkenbare risicobeschrijvingen

Een nuttig risico beschrijft een mogelijke gebeurtenis en het gevolg ervan. “Migratie” is een onderwerp. “Bestaande voorkeurswaarden worden verkeerd omgezet, waardoor sommige klanten optionele e-mails ontvangen die ze verwachtten te stoppen” is een scenario dat mensen kunnen onderzoeken.

Voeg dubbele punten samen zonder verschillende gevolgen kwijt te raken. Meerdere zorgen over oudere accounts kunnen dezelfde oorzaak hebben. Een misleidend label en een mislukte opslag kunnen beide klanten verwarren, maar vragen verschillende controles en moeten meestal afzonderlijke risico's blijven.

Vraag bij elk scenario wat het team vroeg zou opmerken. Een vroeg waarschuwingssignaal is iets waarneembaars dat aandacht verdient. In ons voorbeeld is een verschil tussen bestaande accountinstellingen en de voorgestelde gemigreerde waarden nuttiger dan “klanten kunnen klagen”. Het kan vóór de lancering worden gecontroleerd.

Spreek af wat waarschijnlijkheid en impact betekenen

Power Pack biedt een 3×3- of 5×5-matrix en berekent een ernstscore door waarschijnlijkheid met impact te vermenigvuldigen. Gebruik die score als ondersteuning voor het gesprek en de rangschikking. Het is een subjectieve inschatting, geen voorspelling van hoe vaak een fout zal optreden of een berekening van verwacht verlies.

Voor een eerste sessie kiest ons team 3×3 en spreekt het eenvoudige betekenissen voor de waarderingen af. Waarschijnlijkheid één betekent dat er momenteel weinig ondersteunend bewijs is; twee betekent dat het scenario plausibel is en onderzoek nodig heeft; drie betekent dat er sterke redenen zijn om het zonder actie te verwachten. Dit zijn de werkdefinities van het team.

Ze definiëren impact rond gevolgen voor klant en release. Eén is een beperkt ongemak, twee een betekenisvolle verstoring die opvolging vraagt en drie een ernstig klantprobleem of reden om de release te pauzeren. Een ander team kan andere definities voor de eigen omgeving nodig hebben.

Priya geeft onjuiste migratie waarschijnlijkheid twee en impact drie, voor een score van zes. Het team bespreekt de aannames achter die waardering: de nieuwe omzetting is nog niet geoefend met representatieve oudere accounts. Het ontbrekende bewijs is belangrijker dan de schijnbare precisie van het getal.

Gebruik dezelfde schaal bij het vergelijken van de eerste risico's. Wisselen tussen matrixgroottes schaalt bestaande waarderingen opnieuw, dus bekijk de nieuwe posities als je de resolutie verandert. Een nieuwe positie mag niet worden verward met nieuw ontdekt bewijs over de release.

Voeg de risico's toe aan Power Pack

Open Power Pack op het gekozen Jira-issue en selecteer Risk & Pre-Mortem Grid. Gebruik de heatmap om de verdeling van waarderingen te zien en het risicoregister om de regels te bekijken. Je kunt een risico vanuit een matrixcel toevoegen wanneer je de aanvankelijke waarschijnlijkheid en impact al kent.

Leg voor elke regel de titel, het faalscenario, het vroege waarschuwingssignaal en de categorie vast. Voeg de afgesproken waarderingen, een beheersplan en een verantwoordelijke toe. Power Pack ondersteunt ook controlepunten voor maatregelen, een status en een optionele verwijzing naar een Jira-issue.

De verantwoordelijke kan een Jira-gebruiker of een geregistreerde externe persoon zijn. Kies iemand die de reactie coördineert en ontbrekend bewijs terugbrengt naar het team. Die persoon in de matrix noemen maakt geen Jira-taak aan, wijst geen bestaande taak toe en geeft geen toegang tot het issue.

Bekijk de opslagstatus voordat je de bijgewerkte matrix als gedeeld beschouwt. Wijzigingen worden bij het issue opgeslagen. Een lokale status of een nieuwe opslagpoging is geen bevestiging dat een ander teamlid de nieuwste regel al kan zien.

Geef elk belangrijk risico een praktische reactie

“Grondig testen” is lastig op te volgen. Voor het migratierisico stelt Priya een oefening voor met representatieve bestaande accounttoestanden, gevolgd door een vergelijking van de resulterende voorkeuren en het verwachte e-mailgedrag. Leo onderzoekt verschillen. Priya blijft verantwoordelijk voor het risico en brengt het resultaat naar de releasebeoordeling.

Verdeel de reactie in controlepunten die voortgang zichtbaar maken. Het team kan representatieve gevallen kiezen, de oefening uitvoeren, verschillen beoordelen en de resterende onzekerheid vastleggen. Controlepunten helpen de reactie te organiseren, terwijl het werkelijke bewijs bij het relevante test- of uitvoeringswerk blijft.

Als een maatregel een eigen Jira-ticket nodig heeft, maak het dan aan en wijs het toe via de normale Jira-workflow. Voeg daarna de sleutel als verwijzing aan het risico toe. Een verwijzing maakt het verband makkelijker te volgen; die maakt het werk niet automatisch aan en beheert de oplevering niet.

Bekijk de status opnieuw wanneer het bewijs verandert

Power Pack biedt de statussen Identified, In Progress, Mitigated en Accepted. Gebruik Identified wanneer het scenario is vastgelegd en In Progress wanneer iemand actief aan de reactie werkt. Spreek af welk bewijs het team verwacht voordat je een risico als Mitigated beschrijft.

Accepted kan een bewuste beslissing beschrijven om met een resterende blootstelling door te gaan. Maya kan bijvoorbeeld een klein gat in ondersteuningsdocumentatie accepteren nadat Sam bevestigt dat een tijdelijke reactie beschikbaar is. Leg de redenering vast en bekijk die opnieuw als aannames veranderen. Acceptatie moet een begrepen besluit zijn, geen manier om de matrix op te ruimen.

Vraag tijdens de releasebeoordeling aan verantwoordelijken naar waarschuwingssignalen, resultaten van maatregelen en resterende onzekerheid. Beoordeel elke wezenlijke scopewijziging, nieuwe afhankelijkheid of onverwachte testuitkomst afzonderlijk. Pas waarderingen aan wanneer het bewijs dat rechtvaardigt en leg uit waarom de inschatting veranderde.

Je kunt de matrix als Markdown of CSV exporteren voor een planningsgesprek. Benoem het Jira-issue als de plek om het actuele overzicht te controleren. Een gedeelde export is een momentopname en weerspiegelt mogelijk niet meer de nieuwste inschatting van het team.

Gebruik de sessie om het vervolg te veranderen

Een ingevulde matrix is nuttig wanneer die de voorbereiding beïnvloedt. Voor ons portaalteam leidt de pre-mortem tot een migratieoefening, duidelijkere tekst en een controle of de ondersteuningshandleiding bij de releasekandidaat past. Elke actie behandelt een specifiek faalscenario dat de uitvoerende mensen hebben genoemd.

Begin met één release, een kort begeleid gesprek en een kleine reeks betekenisvolle risico's. Gebruik Power Pack om scenario's, verantwoordelijken en reacties zichtbaar te houden bij het Jira-issue. Neem het overzicht vervolgens mee naar het volgende releasegesprek, waar het team kan beoordelen wat er werkelijk is veranderd.