Jira Cloud – De sky != de limit

Al ruim vijf jaar werken we met ons team met Jira Cloud. En tot voor kort was er ook geen vuiltje aan die spreekwoordelijke ‘cloud’. Echter zijn we er toch achtergekomen dat de limit al was bereikt voordat we bij de sky waren. In deze blog wil ik uitleggen wat we mee hebben gemaakt en welke oplossingen we hebben geïmplementeerd.

Donkere wolken pakken zich samen

Het was eigenlijk best een mooie dag waarop de product owner van ons team zich bij mij meldde. De berichten waren niet goed: nieuw aangemaakte User Stories en Bugs verschijnen niet meer in de Product Backlog. Echter, zodra ze aan een actieve sprint werden toegewezen verschenen de User Stories, Bugs en de bijbehorende subtaken opeens wel op de Sprint Backlog. Het was niet alleen de product owner opgevallen, ook enkele stakeholders kwamen mij hetzelfde nieuws melden.

Na wat rondklikken in Jira en op de Atlassian Community site liep ik al gauw vast. Met mijn hoofd in de mist besloot ik daarom maar een support ticket aan te maken bij Atlassian. Al snel werd ik geholpen en belandde ik meerdere malen van de regen in de drup. Hoewel de User Stories en Bugs nog wel gewoon aanwezig waren in Jira Cloud, kon ik ze alleen niet meer zien. Dat was overigens wel een geruststelling voor de product owner en de stakeholders die zich bij mij hadden gemeld. Echter een kant en klare oplossing was niet voor handen. Het probleem dat zich voordeed werd als volgt beschreven:

If you run your board filter JQL, you will see that it returns 6766 issues, which is more than the limit of 5000 issues.

Work item limits in company-managed projects

Ik had geen idee dat dit ook nog kon. Nu scheelt het ook niet dat iemand uit het team net ongeveer 40 user stories had aangemaakt (met elk 8 subtaken) om zijn plannen vorm te geven. Dat was waarschijnlijk de druppel die deze emmer deed overlopen.

Op zoek naar een paraplu

Om er voor te zorgen dat we weer nieuwe items in de product backlog zouden zien stelde de support medewerker van Atlassian voor om de JQL query van het board filter aan te passen.

Misschien de sorting aanpassen zodat je eerst de nieuwe items ziet? Geen goed idee, dan zie je de oude items niet meer. Plus: je kan dan geen ranking meer toepassen.

Misschien dan de lijst sorteren op datum én ranking? Dat lost het probleem van de ranking wel op, maar nog steeds zie je niet alle items in de backlog verschijnen.

Zitten er misschien nog items in de product backlog waar je helemaal niets meer mee doet? Ja! En daar zat een mogelijkheid!

De lucht klaart op

De initiële JQL van ons board filter zag er als volgt uit:

project = "Project BrightSkies" ORDER BY Rank ASC

Kortom: laat alle items (User Stories, Bugs en Subtaken) maar zien. Echter, dat is niet wat we nodig hebben. Want alles wat we al af hebben, daar zijn we voor de Product Backlog niet meer in geïnteresseerd. Na kort overleg met de support medewerker van Atlassian zijn we tot de volgende JQL gekomen voor ons board filter:

project = "Project BrightSkies" AND Sprint IN (empty, futureSprints(), openSprints()) ORDER BY Rank ASC

Door dit filter te gebruiken zien we geen items meer die in gesloten sprints staan. Echter, dit was niet genoeg. we hadden nog steeds een kleine 1700 items teveel.

Dweilen

Er moest nog een dweilactie plaats vinden. Want na wat zoekwerk kwam ik er achter dat we bijna 350 User Stories en Bugs in Jira hadden staan die op de status “Won’t Do” waren gezet. Daarnaast zijn deze items ook niet aan een sprint gelinkt. Dit waren veelal ideeën die gaandeweg zijn afgeschoten door het team en die nooit geïmplementeerd zouden worden. Deze 350 items hebben allemaal ook 8 subtaken. Door deze allemaal te verwijderen hebben we ongeveer 2500 items uit Jira weg kunnen gooien. Wat erin resulteert dat we nog een totaal van ongeveer 4200 items in onze product backlog hebben zitten.

Regenjas regelen

Om te voorkomen dat we het weer zo nat krijgen van de regen aan product backlog items hebben we nog een extra stukje automatisering aan ons Jira project toegevoegd. Alsof we als team een regenjas aantrokken. Na elke sprint gooien we alle subtaken die op “Won’t Do” zijn gezet weg. De eerste sprint waarbij we dit hadden gedaan scheelde dit direct al 55 subtaken.

Hoe het kan dat we zoveel subtaken hebben? Dat hebben we ook geautomatiseerd. Op basis van de Definition of Done van het team worden er bij het aanmaken van User Stories en Bugs direct een aantal standaard subtaken aangemaakt. Denk aan: bouwen, testen, unit tests maken, end-to-end testen aanpassen, code review, releasen, etc. Soms kan het voorkomen dat een aantal taken niet uitgevoerd hoeven worden. Deze worden dan op de status “Won’t Do” gezet.

Zonnige toekomst

Als we in de toekomst zonnig willen inzien, dan moeten we ook onderkennen dat we onze Product Backlog periodiek moeten opruimen. Dit kan door verschillende filters toe te passen op de bak aan items die in de Product Backlog naar voren komen. Denk bijvoorbeeld aan:

• Items die lang geleden zijn aangemaakt en niet meer relevant zijn om te bewaren;
• Items die op de status “Won’t do” zijn gezet en niet aan een sprint zijn toegekend;
• Items die ooit wel zijn geïmplementeerd maar waarvan de implementatiedatum zo lang is geleden dat het niet meer relevant is om deze te bewaren.

Al met al zijn we van bovenstaande situatie weer wat wijzer geworden. Daarnaast helaas ook een teleurstelling rijker. Het is jammer dat er in de Jira Cloud omgeving blijkbaar een limiet zit op het aantal items dat in de Product Backlog wordt getoond.

Tips?

Als er iemand is die nog een goede opruimactie weet voor Jira Cloud, dan hoor ik het graag. Ook als je denkt: “Ik heb een briljante JQL query voor je board filter”, dan ben ik zeker geïnteresseerd. Voel je dan vooral vrij om dat wat je hebt te delen onder deze blog.

_{Photo by StuartMiles from Freerange Stock}