Story Points en Velocity in Ansible-projecten met Scrum en Jira

Probleem

In Scrum-teams die Ansible-engineeringprojecten beheren, worden technische taken en bugs vaak behandeld als user stories en krijgen ze story points toegewezen. Dit vervormt velocity-metrics door niet-waarde-toevoegende activiteiten op te nemen in de meting van bedrijfswaarde. Bijvoorbeeld, administratieve of onderhoudstaken worden geschat alsof het user stories zijn, wat een vals gevoel van productiviteit creëert. Hierdoor weerspiegelt velocity niet accuraat het vermogen van het team om automatiseringsinhoud te leveren die de organisatie ten goede komt, zoals Ansible-collecties, rollen, modules, inventory-updates via GitOps of verbeterde documentatie. Zonder focus op bedrijfswaarde worden story points ineffectief, omdat ze niet langer betekenisvolle vooruitgang naar organisatiedoelen vertegenwoordigen.

Context

Ansible-projecten combineren vaak ontwikkeling, operaties en onderhoudswerk. In een Scrum-opzet met Jira gebruiken teams tickettypes zoals user stories, bugs en taken. Refinement-meetings zijn cruciaal voor het bespreken en schatten van alle werktypes, inclusief bugs en taken, om een sterk teaminzicht en planning te garanderen. Het kernproduct in deze projecten is Ansible-automatiserings content, inventory en documentation, die lifecyclebeheer versnellen, operaties ontkoppelen en admin-taken automatiseren. Velocity zou vooruitgang in het bouwen van deze inhoud moeten volgen, niet gerelateerde technische klusjes of bugfixes, die metrics kunnen opblazen en perverse prikkels creëren (bijv. meer bugs die schijnbaar waarde verhogen).

Deze richtlijn richt zich op teams die nieuw zijn in automatisering, wat vaak meer inhoudt dan alleen het automatiseren van lifecyclebeheer (LCM) of onderhoud—dit aspect wordt vaak over het hoofd gezien. Het vereist ook een verschuiving naar DevOps, SRE en een “automate-first”-mindset. Dit is een significante verandering, inclusief het adopteren van software-engineeringdiscipline met iteratieve methoden zoals Scrum. Organisaties, projecten en teams worstelen vaak met een effectieve implementatie, aangezien ze te maken hebben met nieuwe concepten zoals het onderscheiden van user stories, epics, taken en bugs. Zonder duidelijke scheidingen wordt planning gecompliceerd, en velocity toont geen productiviteitswinsten naarmate teams ervaring opbouwen.

In contexten zoals de Nederlandse overheid, waar ervaren Ansible-engineers schaars zijn, zijn teams vaak in transitie en leren ze nieuwe vaardigheden. Om productiviteit te maximaliseren, is het aan te raden dat Ansible-engineeringteams zich zoveel mogelijk richten op engineeringtaken, met aparte operatieteams of personeel dat operationele taken afhandelt. Bijvoorbeeld, lifecyclebeheer (LCM) en onderhoudstaken met Ansible zouden moeten worden uitgevoerd door Ansible-operators, niet door engineers. Ansible-engineers leveren inhoud, inventory en documentatie, terwijl aparte operatieteams deze gebruiken. De engineers gebruiken een Ansible-ontwikkelomgeving om deze outputs te leveren, en deze ontwikkelomgeving is de enige die ze onderhouden en waar ze onderhoudstaken uitvoeren. Alle andere omgevingen zijn de verantwoordelijkheid van operatieteams. Deze focus is essentieel voor het faciliteren van het leerproces, wat productiviteit en engineeringcapaciteit zal verhogen door velocity te boosten. Als gevolg hiervan zou het sprintboard en de backlog voor Ansible-engineers en -teams geen werk moeten bevatten dat gerelateerd is aan andere omgevingen, behalve in zeldzame, uitzonderlijke gevallen.

Oplossing

Om velocity nauwkeurig te meten en bedrijfswaarde te benadrukken, neem een strikte aanpak aan voor het categoriseren en schatten van werk in Jira voor Ansible-projecten. Volg deze stappen:

1. Definieer het Product Duidelijk: Identificeer het kernproduct als Ansible-automatiseringsinhoud (collecties, modules, rollen), inventory beheerd via GitOps als de enkele bron van waarheid, en ondersteunende documentatie. Elk werk dat deze niet direct wijzigt of verbetert, zou geen user story moeten zijn.

2. Categoriseer Tickets Passend:

   • Gebruik user stories alleen voor items die bedrijfswaarde leveren door wijzigingen aan Ansible content, inventory of documentation. Ken story points (SP) toe aan deze tijdens refinement.
   • Gebruik taken voor technische activiteiten, administratief werk of ondersteunende taken (bijv. opzetten van pipelines, training of bureaucratie) die niet toevoegen aan het kernproduct.
   • Gebruik bugs voor fixes die bestaande inhoud onderhouden maar niet uitbreiden. Bespreek bugs in refinement voor planningsimpact, maar ken geen SP toe.

3. Refinement-proces:

   • Neem alle tickettypes (user stories, bugs, taken) op in refinement-meetings om de algehele sprintcapaciteit te beoordelen.
   • Ken SP alleen toe aan kwalificerende user stories. Voor bugs en taken, schat inspanning in uren of bespreek kwalitatief om planning te informeren zonder velocity op te blazen.

4. Planning en Velocity-tracking:

   • Baseer sprintplanning op historische velocity van user stories alleen. Houd rekening met bugs en taken door gecommitteerde SP naar beneden aan te passen als ze significante capaciteit verbruiken.
   • Monitor velocity-trends om groeiende expertise te weerspiegelen (bijv. snellere productie van Ansible-inhoud na verloop van tijd).
   • Vermijd sturen alleen op metrics; gebruik gezond verstand om te beoordelen of het werk past in de capaciteit, rekening houdend met alle elementen.

5. Integratie van Retrospectieven: Voer retrospectieven uit om deze praktijken te beoordelen, maak impliciete keuzes expliciet (bijv. erken dat velocity een mix meet als niet strikt gedefinieerd).

Voordelen

• Nauwkeurige Meting van Bedrijfswaarde: Velocity weerspiegelt echte productiviteit in het leveren van Ansible-automatisering, wat helpt bij het volgen van verbeteringen zoals verhoogde inhoudsproductie naarmate teams ervaring opdoen.
• Betere Planning en Capaciteitsbeheer: Door waarde-toevoegend werk te scheiden van taken/bugs, vermijden teams overcommitment en krijgen ze duidelijkheid over impacts op sprints.
• Verminderde Perverse Prikkels: Voorkomt scenario’s waarin meer bugs of bureaucratie metrics kunstmatig boosten, wat focus op kwaliteit en efficiëntie aanmoedigt.
• Verbeterde Focus op Kernproduct: Zorgt ervoor dat inspanningen prioriteit geven aan Ansible-inhoud, inventory en documentatie, in lijn met projectdoelen.

Alternatieven

Een alternatief is het toewijzen van SP aan alle werkitems, inclusief bugs en taken, om tracking te vereenvoudigen. Dit wordt echter niet aanbevolen omdat het verschillende types waarde mixt en metrics vervormt. Standaard staat Jira geen SP-toewijzing toe aan taken en bugs, wat in lijn is met best practices om slechte gewoonten te vermijden. Het aanpassen van Jira (bijv. wijzigen van schermen) om dit mogelijk te maken vereist extra inspanning en is een controversiële beslissing—het signaleert essentieel een organisatorisch beleid tegen focus op bedrijfswaarde. Dit zou moeten worden afgekeurd en niet gepromoot, omdat het teams aanmoedigt praktijken aan te nemen die nauwkeurige velocity-tracking ondermijnen. Een andere aanpak is het gebruik van Kanban voor operatiewerk naast Scrum voor ontwikkeling, maar in gemengde projecten biedt de strikte categorisatie hierboven een gebalanceerde hybride zonder boards te splitsen.

Voorbeelden en Implementatie

In een Jira-opzet voor een Ansible-project:

• User Story-voorbeeld: “Als operator wil ik een Ansible-rol voor het uitrollen van SSSD met Active Directory-integratie zodat authenticatie geautomatiseerd is.” Ken SP toe op basis van complexiteit (bijv. 5 SP). Dit verbetert direct Ansible-inhoud.

• Taak-voorbeeld: “Onderzoeken en documenteren van GitLab-pipeline-verbeteringen voor het testen van Ansible-playbooks.” Geen SP; behandel als taak die ondersteunt maar niet toevoegt aan kerninhoud.

• Bug-voorbeeld: “Oplossen van fout in bestaande Ansible-module voor pakketinstallatie.” Bespreek in refinement voor tijdsimpact, maar geen SP; het onderhoudt waarde zonder nieuw te creëren.

Suggestie voor Bestandsstructuur:

• Organiseer Jira-epics rond Ansible-inhoudsthema’s (bijv. “Inventory GitOps”, “Role Development”).
• Gebruik labels zoals “ansible-content” voor user stories om velocity-rapporten te filteren.

Implementatietip: Tijdens sprintplanning, bekijk een burndown-chart gericht op user story-SP, terwijl taak/bug-uren apart worden genoteerd. Dit zorgt voor zichtbaarheid in al het werk zonder waarde-metrics te vertekenen. Voor nieuwe teams die Ansible-projecten starten, introduceer deze richtlijn in de eerste retrospectief om verwachtingen te stellen.