Agile zegt flexibel om te kunnen gaan met wijzigingen. Ze juicht wijzigingen zelfs toe en stimuleert voortschrijdend inzicht. Een wijziging is namelijk een teken dat je een beetje beter zicht op de daadwerkelijke behoeften van de business hebt gekregen.

Maar wijzigingen in de reeds opgestelde requirements veroorzaken ook extra werk. Daar wordt niemand blij van, zeker het management niet, en al helemaal niet als het negatieve impact heeft op de planning. En dat is precies waar het wringt in organisaties waar het management onvoldoende mee verandert in de transitie van een traditionele naar een agile werkwijze.

Ze willen dan meteen weten hoeveel extra tijd de wijziging kost.

En wie moet vervolgens gaan uitzoeken wat de wijziging precies inhoudt en hoe groot de impact is?

Als je pech hebt, kijkt iedereen naar jou en wordt het ten onrechte een taak van de analisten. Wat in zo’n situatie beter zou zijn, is het bepalen van de impact in je agile werkwijze opnemen. Dat is in organisaties die nog met traditionele planningen en impactanalyses werken waarschijnlijk de best haalbare optie.

Met de volgende 3 stappen kom je tegemoet aan de informatiebehoefte van traditionele managers én verstoor je de agile werkwijze zo min mogelijk.

Stap 1: Nieuwe of bestaande user story

De product owner zoekt (samen met een analist) uit of de gewenste wijziging een nieuwe user story of een wijziging op een bestaande user story moet worden.

Als men genoegen neemt met een grove urenschatting vraag je het ontwikkelteam de omvang van de wijziging te schatten in t-shirt maten of in story points (zie stap 3). Na goedkeuring van de wijziging voegt de product owner de nieuwe of gewijzigde user story op de juiste plek op de product backlog in.

TIP   Laat stakeholders duidelijk zien welke user stories naar achteren schuiven door het invoegen van de wijziging. Plaats de wijziging in het grotere geheel en in de context van de overall businesswaarde die het systeem moet gaan leveren. Leg de stakeholders vervolgens een keuze voor: Wat is belangrijker, user story xyz of de wijziging?
Vragen hoe belangrijk de wijziging is of hoe snel het doorgevoerd moet worden, kun je beter niet doen. Dan krijg je namelijk steevast het antwoord dat het meteen (volgende sprint of zelfs deze sprint) moet.

Als een nauwkeurige inschatting (voor zover mogelijk) op basis van gedetailleerde requirements vereist is, vervolg je met stap 2 en 3.

Stap 2: Refinement

Maak het verder uitwerken van de wijziging/user story onderdeel van jullie (wekelijkse) product backlog refinement. Als het goed is detailleren daarin de product owner/analist, het ontwikkelteam en eventueel de betreffende stakeholder samen de user story. Zodra het ontwikkelteam genoeg informatie heeft om de omvang ervan in te schatten, ben je klaar met het verfijnen van de user story.

TIP   Vergeet de afhankelijkheden met andere teams niet. Geef het aan als je denkt dat de wijziging ook werk voor een of meer andere teams tot gevolg heeft. Zij moeten dan immers ook een impactanalyse uitvoeren.

Stap 3: Schatting

Het ontwikkelteam schat de omvang van de user story in. Hoewel traditionele managers willen weten hoeveel uren het gaat kosten om de wijziging te realiseren, adviseren wij om altijd gebruik te maken van relatieve schattingen (in story points). Die zijn namelijk betrouwbaarder en gemakkelijker te geven dan een schatting in uren.

Met schattingen in story points is de velocity (gemiddelde ontwikkelsnelheid van het team) vast te stellen. Daarmee kun je met behulp van de product backlog (mits geprioriteerd en ingeschat) aangeven in welke sprint welke stories aan de beurt zijn. En ook hoe alles door invoegen van een wijziging gaat schuiven.

Wil het management de impact op de planning toch in uren en geld uitgedrukt zien? Dan kan met eenmalig een beetje hulp een projectmanager of PMO (Project Management Office) de agile planning omrekenen naar een traditionele planning.

TIP   Onze ervaring is dat het management goed overweg kan met het inzicht dat de agile plannings- en voortgangsoverzichten geven. Wel hebben ze even tijd nodig om aan de nieuwe zienswijze te wennen. Voeg daarom bij elke urenschatting ongevraagd een burn down chart toe (en gebruik de visuele plannings- en voortgangsoverzichten van agile vooral ook zelf binnen je eigen team en project).

Traditionele impactanalyse in een agile jasje

De hierboven beschreven werkwijze is voor organisaties met traditionele planningen en fixed price projecten waarschijnlijk de best haalbare werkwijze. Toch is het goed om je te realiseren dat het in feite een traditionele impactanalyse in een agile jasje is.

Vaak is daar ook een RFC (request for change) proces aan gekoppeld, met de ongewenste effecten die daarbij horen. Zo werpt het bijvoorbeeld een drempel op om wijzigingen (beter gezegd verbeteringen) door te voeren. En wat denk je van de tijd die het kost om een impactanalyse uit te voeren.

Wat was ook alweer de reden dat je organisatie agile is gaan werken? Een kortere time to market? Meer flexibiliteit? Meer businesswaarde?

Is het management zich bewust van de bijeffecten en negatieve consequenties van impactanalyses, een RFC proces en traditionele planningen? Misschien is het de moeite waard die bewustwording op gang te brengen door inzichtelijk te maken hoe de impactanalyses jullie werkproces verstoren. Dus hoeveel tijd gaat eraan verloren? Ofwel hoeveel extra tijd hadden jullie aan het realiseren van businesswaarde kunnen besteden? Om het nog concreter voor het management te maken: welke functionaliteit hadden jullie in die tijd kunnen opleveren?

Hoe je, samen met je collega-analisten, het best passende werkproces voor de omgeving en omstandigheden waarin je werkt, vormgeeft, leer je in ons trainings- en coachingsprogramma Agile requirements toepassen in jouw praktijksituatie. De coaching is nu tijdelijk gratis!

Heb jij ook te maken met impactanalyses? Hoe verloopt het vaststellen van de impact van een wijziging in jouw project? Reacties en vragen naar aanleiding van dit artikel stellen we zeer op prijs. Zet ze in het reactieveld hieronder.


 

Vond je dit artikel interessant? Deel het dan met je vakgenoten via de share knoppen aan de zijkant.

Gratis e-book ‘Vliegende start als agile analist’

Met 25 do’s en don’ts voor agile requirements en eens per maand een agile requirements tip
Nicole de Swart

Nicole de Swart

Requirementstechnieken expert

Ik help je de juiste mix van agile en traditionele requirementstechnieken toepassen

Volg Nicole op:

Tips voor de moderne analist

Je ontvangt eens per maand een nieuw artikel. Net zoals meer dan 5.500 collega abonnees.

Share This