Inzicht en transparantie: het visualiseren van langetermijndoelen in een Agile-omgeving

Het begint met inzicht

In deze blogpost beschrijf ik, Micha van Dijk, een aantal stappen die kunnen worden gevolgd om dit inzicht te verkrijgen en te delen met diverse belanghebbenden. Dit inzicht stelt de organisatie in staat om zelfs in situaties waarin de scope nog niet volledig helder is, de controle te behouden. Zonder dit inzicht wordt het immers moeilijk om vast te stellen hoeveel vooruitgang er is geboekt bij het bereiken van de doelstelling en of deze überhaupt nog haalbaar is binnen een gestelde tijd. Om de stappen toe te lichten, maak ik gebruik van een fictieve casus. In deze casus heeft een zorginstelling als doel dat patiënten meer gebruikmaken van online informatie en diensten, om zo de belasting van het klantcontactcentrum te verminderen.

Stap 1: Identificeren van subdoelen en benodigde features

Om het langetermijndoel voor de zorginstelling behapbaar te maken, is het wijs om deze op te splitsen in meerdere subdoelen. Zo wil de zorginstelling bereiken dat patiënten informatie gemakkelijker kunnen vinden op de website en tevens zelf zaken kunnen regelen via een persoonlijke Mijn-omgeving. Deze subdoelen kunnen vervolgens nog verder worden onderverdeeld.

Vervolgens kan voor elk subdoel worden bepaald welke features nodig zijn om het doel te bereiken. Bijvoorbeeld:

• Langetermijndoel: Patiënten sneller voorzien van informatie, zodat ze minder hoeven te bellen met het klantcontactcentrum
  • Subdoel: Informatie op de website is beter vindbaar
    • Subdoel: Algemene informatie is makkelijker te vinden
      • Feature: Algemene informatiepagina’s
      • Feature: Zoekfunctionaliteit
    • Subdoel: Patiënt kan snel antwoord vinden op veelgestelde vragen
      • Feature: FAQ-pagina
      • Feature: Beheermogelijkheid FAQ-pagina
      • Feature: Chatbot
    • Subdoel: Website is toegankelijker voor slechtzienden
      • Feature: Voorlezen tekst
      • Feature: Hoog contrast
  • Subdoel: Patiënt kan eigen gegevens inzien en zaken online regelen
    • Subdoel: Patiënt heeft zelf controle over persoonsgegevens
      • Feature: Basisopzet Mijn-omgeving
      • Feature: Inzien en wijzigen persoonsgegevens
    • Subdoel: Patiënt heeft zelf inzicht in dossier
      • Feature: Inzien bloeduitslagen
      • Feature: Inzien brieven
    • Subdoel: Patiënt kan zelf contact opnemen met behandelaar
      • Feature: E-consult
      • Feature: Video consult
      • Feature: Aanvragen herhaalrecept

Door deze benadering wordt het mogelijk om gestructureerd subdoelen en de benodigde features vast te stellen, die bijdragen aan het verwezenlijken van het langetermijndoel. Deze subdoelen en features zijn flexibel en kunnen in de loop van de tijd worden uitgebreid, verwijderd of gewijzigd. Gedurende het ontwikkelproces wordt er namelijk voortdurend geleerd, wat kan leiden tot nieuwe inzichten en aanpassingen.

Stap 2: Bepalen relatieve omvang van de features

Niet alle features hebben dezelfde omvang. Sommige kunnen binnen een sprint worden voltooid, terwijl andere enkele maanden in beslag kunnen nemen.

Het is niet zinvol om de features tot in detail te schatten, omdat we niet weten tegen welke uitdagingen het ontwikkelteam zal aanlopen. Bovendien heeft het team nog geen volledig inzicht in alles wat er moet gebeuren binnen de features. Met name de features die verder in de toekomst liggen, brengen nog veel onzekerheden met zich mee.

Toch kan het ontwikkelteam redelijk goed inschatten hoe de verschillende features zich qua omvang tot elkaar verhouden. In deze stap gaan we daarom in een Agile planningsessie samen met het ontwikkelteam de features voorzien van T-shirt sizes.

Tijdens deze sessie licht de product owner de features één voor één toe, waarna het ontwikkelteam de bijbehorende T-shirt size bepaalt. Hierbij gelden de volgende regels:

1. Het betreft geen exacte schatting, aangezien nog niet alle details van de functionaliteit bekend zijn.
2. Een volgende T-shirt size vertegenwoordigt ongeveer een verdubbeling in omvang.
3. Het team kan hierbij geen fouten maken. Het is een inschatting op dat specifieke moment, gebaseerd op de beschikbare informatie.

Door regelmatig bijeen te komen en de Agile-planningssessies te herhalen, kunnen we profiteren van de opgedane kennis en nieuwe inzichten. Dit stelt ons in staat om de voortgang en de prioriteiten bij te stellen op basis van de actuele informatie. Zo blijven we flexibel en kunnen we efficiënt inspelen op veranderende omstandigheden gedurende het ontwikkelproces. De ervaring leert dat een frequentie van ongeveer eens in de 2 tot 3 maanden optimaal is.

De vastgestelde T-shirt sizes worden bijgehouden in een spreadsheet. Met het oog op volledige transparantie wordt ook de historie ervan gedocumenteerd. Op deze manier kunnen in de spreadsheet korte opmerkingen worden opgenomen bij belangrijke wijzigingen.

Stap 3: Bepalen voortgang van features

Wanneer een feature bij het ontwikkelteam onderhanden is, is het goed om gezamenlijk te bepalen hoever deze feature gevorderd is. Ook hierbij is het van belang om te realiseren dat dit geen exacte schatting kan zijn. Vooral bij grotere features kan het goed zijn dat nog niet alle benodigde user stories uitgewerkt en duidelijk zijn. In de praktijk kiezen we ervoor om de schattingen niet gedetailleerder te maken dan in stappen van 5 of 10%, waardoor we een vals gevoel van nauwkeurigheid vermijden.

Deze voortgang wordt aan het einde van iedere sprint door het team bepaald. De ervaring is dat het goed werkt als dit na de laatste daily standup van een sprint gebeurt, zodat de informatie meegenomen kan worden in de sprint review.

Ook de vastgestelde voltooiingspercentages worden bijgehouden in de spreadsheet. Met het oog op volledige transparantie wordt ook de historie ervan gedocumenteerd. Op deze manier kunnen in de spreadsheet korte opmerkingen worden opgenomen bij belangrijke wijzigingen.

Stap 4: Inzicht geven in voortgang

We hebben nu een goed inzicht in de relatieve omvang van de features (T-shirt sizes) en de geschatte voortgang van het team bij elke feature. Op basis hiervan kunnen we een globale voortgang bepalen. We weten dat elke volgende T-shirt size een verdubbeling vertegenwoordigt. We kunnen hieraan een numerieke waarde toekennen, welke we inspanningspunten (of ‘effortpunten’) noemen:

• XS: 50
• S: 100
• M: 200
• L: 400
• XL: 800

Het is een bewuste keuze dat we hiervoor een andere eenheid (inspanningspunten) gebruiken dan bij het schatten van user stories (story points). Dit om verwarring tussen beide te voorkomen. Voor elke feature hebben we ook een indicatie van de geschatte voortgang. We hebben namelijk de voltooiingspercentages bepaald. Door deze percentages te vermenigvuldigen met de inspanningspunten, kunnen we een inschatting maken van hoever we ongeveer gevorderd zijn met elke feature. In het huidige voorbeeld zien we dus dat we ongeveer op 38% (925/2450) van het langetermijndoel zijn.

Dit geeft ons een overzichtelijke en kwantitatieve benadering van de voortgang, waardoor we een beter beeld krijgen van hoever we zijn gevorderd ten opzichte van het uiteindelijke doel. Het is belangrijk om te realiseren en expliciet te vermelden dat deze globale voortgang een schatting betreft. Zowel de T-shirt sizes als de voltooiingspercentages zijn geen exacte gegevens en kunnen veranderen gedurende het ontwikkelproces.

Stap 5: Inzicht geven in samenhang

Op basis van de verzamelde gegevens kunnen we dus een globale inschatting maken van hoever we zijn gevorderd in het bereiken van ons langetermijndoel. Echter, uit ervaring blijkt dat het delen van een lijst met getallen en percentages geen helder beeld geeft aan belanghebbenden. Belanghebbenden hebben behoefte aan inzicht in de onderlinge verbanden tussen de verschillende features en de voortgang op de verschillende subdoelen.

Om aan deze behoefte te voldoen, kan er een visuele weergave worden gecreëerd waarin de samenhang en voortgang op verschillende niveaus duidelijk worden gepresenteerd. Deze visuele weergave noemen we het voortgangsdashboard. Door dit dashboard op te nemen in dezelfde spreadsheet, kan deze automatisch worden bijgewerkt wanneer de voltooiingspercentages worden bijgewerkt.

Het voortgangsdashboard biedt een aantal belangrijke voordelen:

1. Het biedt een overzichtelijke weergave van de voortgang op de verschillende niveaus. Op één plek kunnen belanghebbenden direct zien hoever we zijn gevorderd in het realiseren van de subdoelen en implementeren van de features.
2. Het verschaft inzicht in de subdoelen die we nastreven door middel van het implementeren van de features. Dit kan helpen bij het afbakenen van de scope. Wanneer er een nieuwe wens wordt geuit die niet bijdraagt aan het bereiken van het (sub)doel, kan het dashboard duidelijk maken dat deze wens op dit moment niet wordt gehonoreerd. Daarnaast helpt het de leden van het ontwikkelteam begrijpen waarom ze een bepaalde user story binnen een feature ontwikkelen.
3. Het geeft inzicht in de globale omvang van de features. Het wordt direct duidelijk dat elke volgende T-shirt size ongeveer een verdubbeling betekent qua omvang van het werk.

Door dit dashboard regelmatig te delen, kunnen belanghebbenden beter geïnformeerd worden en kan de scope effectiever worden beheerd. De sprint review is hier een geschikt moment voor, omdat het dashboard ook gebruikt kan worden om toekomstige werkzaamheden toe te lichten. Ook bij het delen van het voortgangsdashboard is het essentieel om te benadrukken dat de vermelde voortgang gebaseerd is op globale schattingen (T-shirt sizes en voltooiingspercentages). Om die reden staat dit ook als disclaimer vermeld.

Stap 6: Continu bijwerken

Een product owner moet te allen tijde inzicht kunnen bieden in de voortgang naar een doel. Wanneer de werkwijze uit deze blogpost wordt gevolgd betekent dit dus dat het dashboard continu bijgewerkt moet zijn.

Het opzetten van het dashboard vergt initieel vrij veel inspanning, maar daarna wordt het onderhouden ervan aanzienlijk eenvoudiger. Na iedere sprint moeten de voltooiingspercentages worden ingevuld in de spreadsheet. Deze percentages kunnen vervolgens automatisch worden bijgewerkt op het dasboard. De voltooiingspercentages van de features kunnen rechtstreeks overgenomen worden uit de spreadsheet. De voltooiingspercentages van de subdoelen kunnen worden berekend op basis van de T-shirt sizes en de voltooiingspercentages van de onderliggende features.

Na iedere Agile planningsessie moeten de nieuwe T-shirt sizes in de spreadsheet worden geregistreerd. Features waarvan de T-shirt size gewijzigd is, moeten daarnaast visueel breder of smaller gemaakt worden om hun relatieve omvang weer te geven. Dit is een handmatige actie. Dat is echter geen groot probleem, omdat dit slechts eens in de 2 à 3 maanden hoeft te gebeuren. Ook wanneer features worden toegevoegd of verwijderd, moet het dashboard handmatig worden aangepast. Gelukkig komt dit minder vaak voor.

Tot slot

Sinds ik als product owner volgens deze methodiek ben gaan werken, heb ik gemerkt dat ik meer controle heb over het behalen van gestelde doelen. Het voortgangsdashboard wordt regelmatig bijgewerkt en gedeeld, wat de transparantie aanzienlijk vergroot. Dankzij het dashboard beschik ik over een krachtige tool waarmee ik gefundeerde discussies kan voeren over de haalbaarheid van onze doelen. Op deze manier kunnen we tijdig bijsturen indien nodig. Bovendien helpt het dashboard mij bij discussies over de scope. Als een nieuwe wens geen bijdrage levert aan het behalen van ons doel, kan deze zonder te veel discussie geparkeerd worden. Het beste van alles is dat deze werkwijze weinig inspanning vergt van zowel het ontwikkelteam als van mijzelf.