Prioriteren kun je leren!

door | jul 28, 2019

Prioriteit is afgeleid van het vroegere ‘prior thing’. Oftewel de focus leggen op dat ene wat belangrijk is. Tegenwoordig werken we met prioriteiten. Dingen die belangrijker zijn dan andere dingen.

Maar.. we hebben Scrum en Agile bedacht als oplossing om zaken af te krijgen en op te leveren. Even de juiste prioriteit(en) stellen en we kunnen aan de slag! Maar hoe krijg je de focus op de juiste prioriteit(en), zodat je team gemotiveerd is om op te leveren, maar je stakeholders niet gefrustreerd raken omdat je een keuze hebt gemaakt?

5 tips die je helpen bij het prioriteren binnen Scrum:

1. Bepaal het doel.

Zonder doel heeft het team geen richting en ontstaat er ruis over waarom dit door het team opgepakt moet worden. Hoort dit wel op onze Backlog, waarom moeten wij dit doen? Als het doel duidelijk is, dan kan het team werken aan een MVP. Een MVP is een minimal viable product; dat wat nodig is om de werking en potentie van het product aan te tonen, zodat de gebruiker feedback kan geven.

Valkuil:

Een MVP is geen kant en klaar afgerond product, stel feedback loops daarom niet uit tot het moment dat het product klaar is. Elke sprint is een kans op product- en proces verbetering, die laat je niet liggen! 

2. Wie is erbij betrokken?

Voordat er tijd en geld geïnvesteerd wordt, is het belangrijk om te weten wie het mandaat heeft om keuzes te maken over de prioriteit, of misschien juist deze keuzes terug te draaien.

Als ProductOwner is het belangrijk dat je weet welke krachten er gaan spelen als je het product gaat ontwikkelen. Een stakeholder analyse in combinatie met een RACI zijn goede tools om de omgeving van het team in kaart te brengen.

Daarna is het essentieel om te weten welke afhankelijkheden er bestaan. Kan jouw team starten en opleveren zonder afhankelijkheden? Enkele veelvoorkomende voorbeelden van afhankelijkheden zijn; admin-rechten, management goedkeuring en ontbrekende disciplines als design, test of front-end capaciteit.

En dan zijn er ook nog afhankelijkheden die kunnen bestaan omdat je werkt met leveranciers voor hardware of software. Wat zijn de levertijden en -betrouwbaarheid van deze partijen? Hebben we gelijkwaardige opties, of SPOF’s (single point of failure) in onze keten?

Valkuil:

Scrum is een uitstekend proces voor marktverkenning en experimentele ontwikkeling. Maar beginnen met impliciete aannames zonder deze te testen in het stakeholderveld, bijvoorbeeld met hypotheses, is een groot risico op verlies van geld, tijd en moraal.

3. Wat wordt er verwacht?

Doel bekend? Check! Afhankelijkheden bekend? Check!

Bepaal nu waarmee gestart kan worden. Bespreek met het team welke informatie er vooraf bekend moet zijn voordat het team tijd gaat stoppen in refinement of zelfs oplevering. In een refinement sessie bespreekt de PO met het team wat de gebruikerswensen (value) zijn om zoveel mogelijk duidelijkheid te krijgen. Op basis van de beschikbare informatie definieert het team welke werkzaamheden er nodig zijn om de klantwens te realiseren. Hierbij hoort ook een inschatting (effort) met bijvoorbeeld story points. Op basis van de value / effort verhouding kan de PO met de stakeholders transparant maken wat prioriteit krijgt en waarom.

Als het niet bekend is voor welke persona of gebruikerstype dit gemaakt moet worden begin er dan nog niet aan. Aannames en verschillende oplossingsrichtingen zijn een risico als het werk wordt opgepakt. Verspil daarom geen kostbare tijd aan onduidelijke user stories of onduidelijke gebruikerswensen. Overproductie op basis van aannames is zonde van het geld!

Valkuil:

Er is een duidelijke rollen scheiding in Scrum tussen wat (PO) er moet gebeuren en hoe (team) dit bereikt kan worden. Als de PO een inschatting (hoe) geeft zonder teamleden hierbij te betrekken bestaat de kans op miscommunicatie. Als het team aannames doet over gebruikerswensen (wat) zonder de PO erbij te betrekken bestaat de kans op overproductie. Blijf bij je rol en zorg voor een gestroomlijnde samenwerking in jouw team.

4. Deadline of fixed scope?

Als je weet wat – en waarom – er opgeleverd moet worden, is het vervolgens belangrijk om te weten wanneer het gewenst is. Op basis van deze deadlines en de gevraagde functionaliteit kan de Backlog geprioriteerd worden op de hoogste waarde voor de gebruiker. Op basis van ‘velocity’ kan de PO samen met de stakeholders een inschatting maken op wat er klaar is op de gestelde deadline, of wanneer de gevraagde functionaliteit klaar is.

Wat is Velocity?

Per sprint heeft het team een bepaalde capaciteit (vaste groep mensen X aantal werkdagen). Met deze capaciteit in het achterhoofd gaat het team op basis van de backlog een sprint planning maken. Het team neemt steeds het bovenste item van de backlog, bespreekt de werkzaamheden en kijkt of de inschatting uit de refinement nog past bij de inzichten van dat moment. De sprint backlog is vol als het team dit aangeeft. De optelling van story points is een getal dat de ‘workload’ kan weergeven. Aan het einde van de sprint wordt gekeken welk deel van de ‘workload’ gehaald is. Dit heet ‘velocity’. Over een aantal sprints genomen geeft deze velocity een indicatie wat het team aankan per sprint.

Valkuil:

Velocity wordt soms gebruikt voor een forecast op basis van fixed scope, fixed time (old school projectmanagement). Velocity is geen belofte en ook geen management informatie. Het is slechts een stuur mechanisme voor en door de teamleden om de ‘workload’ in te schatten.

5. Commitment & transparantie.

Op basis van de Product Backlog stelt de PO sprint doelen. Naast dat een sprintdoel de onderhandeling met stakeholders bevordert, zorgt het ook voor focus voor het team. In de Daily Scrum geeft het doel houvast om te bepalen wat er nodig is om de meeste waarde op te leveren en eventuele zij-invliegers te parkeren voor later.

Op basis van de vorderingen per sprint, maakt het team transparant wat er opgeleverd is en opgepakt gaat worden (sprint review). Maar ook welke scope er nog open staat, bijvoorbeeld voor het opleveren van het MVP. Deze transparantie zorgt voor vertrouwen in de voortgang, openheid over de werkelijke prestatie en de bruikbaarheid en kwaliteit van het product.

Valkuil:

In de Daily Scrum kan de focus op task management komen te liggen als er alleen een rondje gemaakt wordt om elkaar te updaten wie met welke taak aan de slag gaat of klaar is. Gebruikerswensen, integratie en de afgesproken WIP (work-in-progress) limit kunnen dan op de achtergrond raken.

Op een transparante manier prioriteren is belangrijk, maar ook lastig. Er is namelijk niet één goede manier. Ondanks dat er valkuilen op de loer liggen, kun je met open communicatie en goede afspraken jouw rol als ProductOwner vervullen. Zorg dat je een plannetje maakt met jouw ScrumMaster om enerzijds de omgeving te helpen bij het adopteren van Scrum, en anderzijds stakeholder management een belangrijk onderwerp te maken voor en met het team.

Wat vind jij lastig aan prioriteren? Laat het ons weten, we helpen je graag.

Groet,

Het team van Epic Agility

Geschreven door

Jeroen Molenaar