Story points en velocity in Ansible-projecten met Scrum

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 automatiserings_content_ te leveren die de organisatie ten goede komt, zoals Ansible-collecties, rollen, modules, inventaris-updates via GitOps of verbeterde documentatie. Zonder focus op bedrijfswaarde worden story points ineffectief, omdat ze niet langer betekenisvolle vooruitgang naar organisatiedoelen vertegenwoordigen.

Een ander symptoom van deze verkeerde aanpak is dat refinements veel tijd in beslag nemen en Ansible-gerelateerde onderwerpen zelden worden besproken, omdat aanzienlijke energie wordt besteed aan het verfijnen en schatten van technische taken die geen bedrijfswaarde toevoegen. Deze taken zouden niet de focus moeten zijn, behalve om ze te erkennen als potentieel “verspilde” inspanning.

Een verdere indicator is het niet gebruiken van Fibonacci-getallen voor schattingen, maar in plaats daarvan uren (bijv. vier uur behandelen als één SP). Dit suggereert dat items die als user stories zijn gelabeld, geen echte user stories zijn, wat juiste pokerplanningsessies met Fibonacci onmogelijk maakt. Het wordt uitdagend om kleine, middelgrote of grote user stories te identificeren, omdat de items fundamenteel verschillen van werkelijke waarde-toevoegende stories.

Context

Ansible-projecten combineren vaak ontwikkeling, operaties en onderhoudswerk. In een Scrum-opzet gebruiken teams tickettypes zoals user stories, bugs en taken. Refinement-meetings zijn cruciaal voor het bespreken en schatten van alle werktypes om een sterk teaminzicht en planning te garanderen. Het kernproduct in deze projecten is Ansible-automatiserings_content_, inventaris en documentatie, die lifecyclebeheer versnellen, operaties ontkoppelen en admin-taken automatiseren. Velocity zou vooruitgang in het bouwen van dit product 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. Belangrijke punten zijn:

• Verschuiving naar DevOps, SRE en een “automate-first”-mindset, wat een significante verandering is.
• Adopteren van software-engineeringdiscipline met iteratieve methoden zoals Scrum.
• Worstelingen 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:

• Laat Ansible engineering-teams zich richten op engineeringtaken, met aparte operatieteams die operationele taken afhandelen.
• Bijvoorbeeld, LCM en onderhoud met Ansible zouden moeten worden uitgevoerd door Ansible operators, niet door engineers.
• Engineers leveren content, inventaris en documentatie, terwijl operatieteams deze gebruiken.
• Engineers onderhouden alleen hun Ansible-ontwikkelomgeving; alle andere omgevingen zijn de verantwoordelijkheid van operaties.

Deze focus faciliteert het leerproces, verhoogt productiviteit en engineeringcapaciteit, en boost velocity. Als gevolg hiervan zou het sprintboard en de backlog voor Ansible engineers geen werk moeten bevatten dat gerelateerd is aan andere omgevingen, behalve in zeldzame gevallen.

Oplossing

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

1. Definieer het product duidelijk: Identificeer het kernproduct als Ansible-automatiserings_content_ (collecties, modules, rollen), inventaris 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, inventaris of documentatie. 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 content 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 content 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 content-productie 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 content, inventaris en documentatie, in lijn met projectdoelen.
• Flexibiliteit met onvoltooide taken: Als technische taken niet als SP worden geregistreerd, is het geen probleem als ze niet in de sprint worden afgerond, omdat ze velocity niet beïnvloeden. Dit is logisch voor taken zoals het geven van een workshop voor kennisoverdracht aan externe partijen, die afhankelijk kunnen zijn van agenda’s en beschikbaarheid, of het aanvragen van een serviceaccount bij een externe partij, wat sprintgrenzen kan overschrijden zonder kernmetrics te beïnvloeden.

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 staan tools zoals Jira geen SP-toewijzing toe aan taken en bugs, wat in lijn is met best practices om slechte gewoonten te vermijden. Het aanpassen van de tool (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 niet moeten worden 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 opzet voor een Ansible-project (bijv. met Jira of vergelijkbare tools):

• 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 content.

• 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 kern_content_.

• 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 epics rond Ansible content-thema’s (bijv. “Inventory GitOps”, “Role Development”).
• Labels zijn flexibeler voor filteren, zoals “rfr” voor ready for refinement of “rfs” voor ready for sprint. Components kunnen worden gebruikt voor categorieën zoals “ansible-collection”, “inventory” of “execution-environment”, maar labels volstaan voor de meeste filterbehoeften. Overweeg beide te gebruiken als je Jira-opzet baat heeft bij gestructureerde components.

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.