samen
werken
Prioriteiten stellen in Scrum Projecten (Prioriteren van de Backlog)
Het stellen van prioriteiten vinden we lastig. Waarschijnlijk komt dat doordat als je kiest om iets nu te doen, je tegelijkertijd kiest om iets anders later of niet te doen. In dit blog gaan we in op:
- Hoe prioriteer je in Scrum projecten?
- Hoe leer je om keuzes te durven maken?
- Wat zijn de factoren op basis waarvan je prioriteiten kunt stellen?
- Wat is de matrix van Eisenhower?
Prioriteren in Scrum projecten
De Product Backlog, een geprioriteerde lijst met items (ook wel User Stories genoemd), is de enige bron van input voor je Scrum project. Door de items continue te herprioriteren haal je de maximale waarde uit de Product Backlog. Belangrijke items staan bovenaan de Product Backlog en minder belangrijke items staan daar onder. De lijst is dus geprioriteerd van boven naar beneden. Items onderaan zijn geparkeerd voor de toekomst en kunnen later wel of niet opgepakt worden. De items bovenaan de lijst hebben meer detail zodat ze ‘sprintbaar’ zijn, ze zijn deze sprint op te pakken door de Developers (voorheen het Development Team genoemd). Kort gezegd houdt prioriteren in: de juiste dingen op het juiste moment doen.
Klik op de product backlog voor een groot (A0-formaat) template voor een Product Backlog
De Product Owner is de enige verantwoordelijke voor de prioritering van de Product Backlog. Deze stelt hij/zij op basis van de wensen en ambities van stakeholders op. Input voor de Product Backlog komt dus waarschijnlijk van verschillende belanghebbenden. Dat maakt het universeel en tegelijk ook complex. Want hoe bepaal je nu uit al die wensen en ambities wat belangrijk is? In deze blog gaan we dieper in op het prioriteren van de Product Backlog.
Prioriteren begint met de capaciteit om keuzes te durven maken
Als Product Owner kan je er een dagtaak aan hebben om stakeholders te managen. Allerlei belanghebbenden willen voortdurend iets van je project. Input, status updates, invloed uitoefenen, kortom allerlei communicatiestromen die gemanaged moeten worden. Daarom is het belangrijk dat je niet alleen het mandaat hebt om keuzes te maken, maar ook durft deze keuzes daadwerkelijk te maken. Dit betekent dat je stakeholders soms tevredenstelt en in sommige gevallen moet teleurstellen. Als spin in het web van stakeholders ben je als Product Owner de enige persoon die alle wensen en ambities ophaalt en bepaalt met welke je verder gaat. Hier speelt het hebben van lef/moed (courage), een van de 5 Scrum Values, dus een belangrijke rol.
Definiëren waar ‘belangrijk’ voor staat
Een geprioriteerde Product Backlog is een lijst van belangrijke items van boven naar beneden. Om dit goed te doen is het noodzakelijk eerst een heldere definitie van ‘belangrijk’ te hanteren. In sommige gevallen zijn items belangrijk omdat deze maximale waarde leveren voor de klant, in andere gevallen worden ze juist vroegtijdig getoetst om risico’s bijtijds inzichtelijk te maken. Wij onderscheiden 4 verschillende variabelen: ‘waarde’, ‘risico’, ‘opleverbaarheid’ en ‘afhankelijkheid’. Uiteraard zijn er nog vele andere vormen te bedenken afhankelijk van jouw Scrum-project.
Waarde
Dit kan zijn in de vorm van omzet, marge, maar ook in de vorm van kostenbesparing. Denk bijvoorbeeld aan een bedrijf dat een nieuw product in de markt zet. Dit product is een verbeterde versie van een voorganger. Niet alleen zijn er technologische besparingen in het materiaal, het product bevat ook nieuwe onderdelen die de consument heel belangrijk vindt. Er zijn meer mensen die het product gaan kopen, wat betekent dat de omzet ook toeneemt. Een kostenbesparing en omzetgroei in één zorgen voor een hoge waarde.
Risico
In sommige gevallen is het wenselijk om binnen een Sprint vroegtijdig items op te pakken die risico’s toetsen. In traditionele projecten zie je vaak dat een product in een keer met een Big Bang wordt opgeleverd. Hier zitten risico’s aan omdat onderdelen niet vroegtijdig getoetst zijn. Door veel nieuwe onderdelen aan een product toe te voegen heb je een innovatief product, met veel risico’s. Als er een onderdeel niet relevant is, of zelfs tegenwerpingen blijkt te hebben, loopt je totale project het risico volledig te falen. Liever toets je tussentijds dus op risicovolle onderdelen, zodat je vroegtijdig kan falen en er tijd en ruimte voor aanpassing is zodat de maximale waarde van het product te leveren is.
Opleverbaarheid (releasability)
Wanneer een item snel en eenvoudig is op te leveren, kan je ervoor kiezen deze bovenaan te prioriteren. Het gaat hier om het zogeheten ‘laaghangende fruit’ of de ‘quick wins’ die zorgen voor snel resultaat. Belangrijke stakeholders kunnen op basis van de vroege oplevering snel feedback geven, die relevante input vormt voor de volgende oplevering. De mate van opleverbaarheid kan ook samenhangen met de MVP – Minimum Viable Product. Items op de Product Backlog vormen tezamen de minimale functionele eisen van een waardevol product. Je prioriteert de items die betrekking hebben op de MVP.
Afhankelijkheid
Een project kan stil komen te liggen omdat er afhankelijkheden in dit project zitten. Een Scrum Team is bijvoorbeeld afhankelijk van mensen buiten het team of de voortgang van projecten bij een andere afdeling. Afhankelijkheden wil je dus zoveel mogelijk voorkomen in je Product Backlog. Als deze onvermijdelijk zijn, dan is het belangrijk te bepalen hoe je hiermee om gaat. Je kunt er bijvoorbeeld voor kiezen het item op te knippen, zodat je de afhankelijkheid eruit haalt en daarmee het deel wat onafhankelijk is boven aan de Product Backlog prioriteert. Het deel wat een afhankelijkheid bevat prioriteer je lager op de Product Backlog.
De prioriteiten-matrix van Eisenhower
In het dagelijks werk zijn er vaak allerlei belangrijke to do’s en dan zijn ze ook allemaal nog eens urgent. ‘Alles is belangrijk’ is een veelgehoorde kreet, maar dat maakt dit gevoel niet altijd waar. Achteraf blijkt dat zaken niet relevant waren of dat belangrijke ‘spoedjes’ zichzelf al opgelost hebben tegen de tijd dat je ermee aan de slag gaat. Met een reële blik naar items kijken is dus essentieel. Een handig hulpmiddel bij het maken van keuzes in prioriteiten is de prioriteitenmatrix van Eisenhower. Deze matrix kenmerkt zich door twee assen; ‘(on)belangrijk’ en ‘(niet) urgent’.
- Belangrijk: deze actie moet gebeuren, indien dit niet gebeurt kunnen er problemen ontstaan, vertragingen of middelen in het gedrang komen
- Onbelangrijk: er zijn geen negatieve gevolgen wanneer deze actie niet wordt uitgevoerd
- Urgent: de actie moet snel gebeuren, bijvoorbeeld nu meteen of vandaag
- Niet urgent: de actie moet gebeuren, maar kan nog even wachten
Door acties te clusteren in de matrix help je jezelf keuzes te maken in welke items prioriteit hebben. De matrix kent 4 kwadranten: belangrijk/urgent, belangrijk/niet urgent, niet belangrijk/urgent en niet belangrijk/niet urgent.
Kwadrant 1: DOEN
Dit kwadrant kenmerkt zich door items die belangrijk en urgent zijn. Het oppakken van deze items moet dus direct. Deze krijgen altijd voorrang op andere items en taken. Denk bijvoorbeeld aan een gebruikersonderzoek dat eerst gedaan moet worden om te bepalen op welke doelgroep je je wilt focussen. Let er wel op, dat indien er te veel taken in dit kwadrant zitten, je nagenoeg alleen maar bezig bent met brandjes blussen. Richt je daarom ook op kwadrant 2 waardoor items niet meer urgent zijn en je ze meer planmatig kunt oppakken.
Kwadrant 2: LATER
Dit kwadrant kenmerkt zich door items die belangrijk en niet urgent zijn. Het oppakken van deze items kan dus nog even wachten, bijvoorbeeld bij de volgende of daaropvolgende Sprint. Het kan bijvoorbeeld zo zijn dat je in het gebruikersonderzoek eerst een kwalitatief gedeelte wilt houden en daarna pas een kwantitatief gedeelte. In dat geval pak je eerst (Sprint 1) het kwalitatieve gedeelte op en in Sprint 2 het kwantitatieve gedeelte. Het kwantitatieve gedeelte zit in kwadrant LATER.
Kwadrant 3: DELEGEREN
Dit kwadrant kenmerkt zich door items die urgent zijn maar niet belangrijk. De urgentie geeft aan dat het snel moet gebeuren, om te voorkomen dat het zijn relevantie verliest. Denk hierbij aan het terugbellen naar het onderzoeksbureau voor NAW-gegevens. Deze actie heeft geen invloed op het gebruikersonderzoek zelf, maar is wel urgent om de samenwerking op te starten. Je zou dit een van je collega’s (buiten het Scrum Team) kunnen laten doen.
Kwadrant 4: DUMPEN
Dit kwadrant kenmerkt zich door items die niet urgent zijn en ook niet belangrijk. Kort gezegd is er geen relevantie. Zorg ervoor dat je deze items volledig verwijdert van je lijst om onnodige vertroebeling van de Product Backlog te voorkomen. Bijvoorbeeld indien je op basis van het gebruikersonderzoek op een specifiek onderdeel gaat focussen waardoor bepaalde items niet meer relevant zijn.
Conclusie
De Product Backlog is een geprioriteerde lijst met items. Prioriteren is een essentiële activiteit om continu de meest waardevolle items op het juiste moment op te leveren. De Product Owner is hiervoor verantwoordelijk en moet daarbij in staat zijn keuzes te kunnen en durven maken. Dit vergt lef en moed, waarbij je soms stakeholders tevreden zult stellen en soms teleur zult stellen. Als Product Owner bepaal je wat belangrijk is en het is dan ook goed een eenduidig begrip te vormen van wat dat inhoudt. Variabelen waar je op kunt prioriteren zijn: waarde, risico, opleverbaarheid en afhankelijkheid. De prioriteitenmatrix is ten slotte een handig hulpmiddel bij het prioriteren. Op basis van de belangrijkheid en de urgentie maak je keuzes of en wanneer je items oppakt.
Heb je er wel eens aan gedacht om Product Owner te worden? Volg dan onze Product Owner training of neem eens contact met ons op om vrijblijvend telefonisch kennis te maken met een van onze ervaren Agile trainers & coaches. We beantwoorden je vragen graag, bel 020 2614 195.
Ook interessant:
- Stakeholder Management in Scrum (+ template)
- De Product Backlog: Wat je Moet Weten (+ Template)
- Product Owner: de 5 belangrijke taken (+ template)
- Een Product Owner training volgen?
- Wat is een User Story
- Scrum values
