Productbacklog versus sprintbacklog: belangrijkste verschillen
Backlogs vormen de ruggengraat van Agile werkprocessen en begeleiden teams van ideeën tot uitvoering. Een veelvoorkomende valkuil is echter dat er geen onderscheid wordt gemaakt tussen productbacklogs en sprintbacklogs—een fout die kan leiden tot verkeerd afgestemde prioriteiten, inefficiënte sprints en gefrustreerde teams.
Hoewel velen van ons ervaring hebben met software voor backlogbeheer, kan het verkeerd gebruiken van deze twee verschillende hulpmiddelen meer verstoring dan duidelijkheid veroorzaken.
Dus hoe zorgen we ervoor dat onze backlogs vóór ons werken en niet tegen ons? Hun unieke rollen begrijpen gaat niet alleen over definities—het gaat om het oplossen van veelvoorkomende problemen in werkprocessen en het optimaliseren van de samenwerking binnen het team. Laten we hun verschillen uiteenzetten en bekijken hoe we ze effectief kunnen gebruiken.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
Wat is een productbacklog?
Een korte en vereenvoudigde uitleg van wat een productbacklog is: het is een overzicht van alle functies en activiteiten waaraan jij en je ontwikkelingsteam van plan zijn te werken.
Voor een meer gestructureerde definitie verwijzen we naar Atlassian.
Je hebt misschien gemerkt dat de mensen bij Atlassian twee belangrijke concepten benadrukten bij het definiëren van de backlog.
1. De backlog is geprioriteerd.
Een eenvoudige lijst maken van dingen die gebouwd moeten worden, resulteert óf in een enorme puinhoop óf in een product dat de problemen van je gebruikers niet goed kan oplossen. Een lijst met functies is dus niet echt een productbacklog tenzij je er prioriteiten aan toekent.
2. De backlog is afgeleid van de roadmap.
Ik heb zoveel backlogs gezien die simpelweg het resultaat waren van iedereen die zijn functie-ideeën deelde en aan de backlog toevoegde. Dit leidt tot een puinhoop en een product dat eruitziet als het monster van Frankenstein. Als je wilt dat je backlogitems een specifiek product- of bedrijfsdoel bereiken, moet je de backlog opbouwen op basis van je roadmap en productvisie.
Het belangrijkste doel van een backlog is in de eerste plaats om één bron van waarheid voor iedereen binnen het bedrijf te creëren. Er zou altijd één backlog moeten zijn waar iedereen naar verwijst bij het bepalen van wat er vervolgens moet gebeuren.
Daarnaast is een productbacklog ook een uitstekend hulpmiddel om prioritering voor jou en je belanghebbenden te faciliteren, omdat je alles wat je moet doen in de vorm van één lijst bij elkaar hebt.
Wat moet een backlog bevatten?
Als je ervan uitgaat dat je een van de Agile-frameworks gebruikt, bestaat je productbacklog uit de volgende items:
- Epics: Grote functies die je helpen specifieke productdoelen te bereiken, zoals het verhogen van conversie, het oplossen van een specifiek probleem van gebruikers of het verbeteren van hun klantreis binnen je product. De functie voor het plaatsen van opmerkingen in Google Documenten is hier een voorbeeld van. Epics bestaan doorgaans uit kleinere “subfuncties” die user stories worden genoemd.
- User stories: Kleine functies of onderdelen van een functie die bruikbaar zijn voor je klanten. In de hierboven genoemde Google Documenten-functie zijn “iemand in een opmerking vermelden” of “een opmerking oplossen” typische voorbeelden van stories binnen die Epic.
- Technische taken: Werkzaamheden die je ontwikkelingsteam moet uitvoeren en die geen verband houden met de functies in je backlog. Voorbeelden van zulke taken zijn het instellen van een back-updatabase, het herstructureren van een microservice of het optimaliseren van querysnelheden.
- Fouten: Het is geen echte backlog als er geen fouten in staan. Hoe goed je je functies ook ontwikkelt en test, deze kleine parasieten zullen altijd opduiken. Je moet ze dus ergens bijhouden, volgen en beheren. De beste aanpak is om ze in je backlog op te slaan en er net als aan elk ander backlogitem prioriteit aan toe te kennen.
Zo ziet een typische productbacklog eruit:
P.S. Lees ons artikel over 3 voorbeelden van een goed uitgewerkte productbacklog als je op zoek bent naar meer richtlijnen.
Laten we nu de rol van de productmanager bij het werken met de backlog bekijken.
Wie is verantwoordelijk voor het beheren van de backlog?
Kort gezegd: de productmanager is de god van de backlog. Die bepaalt wat er wordt gebouwd, in welke volgorde en waarom. De backlog is diens domein, en de productmanager is uiteindelijk verantwoordelijk om ervoor te zorgen dat deze afgestemd blijft op de productvisie, gebruikersbehoeften en bedrijfsdoelstellingen.
Dat betekent niet dat de PM de enige is die aan de backlog werkt. Engineers, ontwerpers en andere teamleden kunnen items voorstellen of zelfs toevoegen, maar wijzigingen moeten plaatsvinden onder toezicht van de PM. Een chaotische backlog leidt immers tot een chaotisch product.
De belangrijkste verantwoordelijkheden van een PM met betrekking tot de backlog zijn:
- De backlog prioriteren – Ervoor zorgen dat het meest waardevolle en impactvolle werk als eerste wordt aangepakt.
- Deze samen met het team verfijnen – Items regelmatig beoordelen, bijwerken en opsplitsen om het werk duidelijk en uitvoerbaar te houden.
- Backlogprioriteiten en wijzigingen communiceren – Belanghebbenden op de hoogte houden, zodat er geen verrassingen zijn.
Omdat de backlog een levend document is, evolueert deze voortdurend. Er ontstaan nieuwe ideeën, prioriteiten verschuiven en sommige functies worden volledig geschrapt. Deze veranderlijkheid is een belangrijk principe van Agile: de backlog moet de nieuwste realiteit weerspiegelen, niet een star, verouderd plan.
Een goed beheerde backlog is niet zomaar een takenlijst; het is een strategisch hulpmiddel dat teams helpt om op het juiste moment het juiste product te bouwen. En in het middelpunt van dit alles? De productmanager, die de sleutels in handen heeft.
Een productbacklog creëren en beheren: de basis
Je begint met het opbouwen van de eerste versie van je backlog zodra je productroadmap is voltooid. Meestal neem je alle belangrijke functies en werkonderdelen uit de roadmap en zet je deze om in epics op de backlog.
Daarna begin je voor elk daarvan je productvereistedocumenten op te stellen en creëer je epics op basis van de uitsplitsing van de functionaliteit in je PRD.
Maar als natuurlijk gevolg van productontwikkeling zul je deze epics voortdurend blijven wijzigen, zelfstandige gebruikersverhalen en bugs toevoegen en uiteindelijk een backlog krijgen die lijkt op waar de meesten van ons mee werken. Ik bedoel: een rommelige backlog.
Maar je backlog is redelijk eenvoudig te onderhouden als je:
- Regelmatig sessies voor backlogverfijning organiseert.
- Tijd reserveert in de volgende sprint om een groot aantal bugs op te lossen en je backlog daarvan op te schonen.
- Niet iedereen toestaat om ideeën aan de backlog toe te voegen zonder dit eerst met jou te overleggen.
- Je backlog voortdurend prioriteert.
- Gebruikersverhalen in kaart brengen gebruikt om een duidelijk overzicht te hebben van wat er moet gebeuren.
Wat dat laatste betreft, zijn hier twee belangrijke prioriteringstechnieken die ik je zou aanraden op basis van mijn uitgebreide ervaring met het uitproberen van een tiental technieken.
MoSCoW
Dit is een vrij eenvoudige techniek waarbij items op de backlog in deze vier categorieën worden ingedeeld:
- Must-have: Wanneer de functie deel uitmaakt van een essentiële gebruikersreis en je de pijnpunten van gebruikers niet zonder deze functie kunt oplossen. Spotify-afspeellijsten zijn bijvoorbeeld een must-have.
- Should-have: Een belangrijke verbetering van de gebruikersreis. In het geval van Spotify zou dit de mogelijkheid zijn om vooraf gemaakte afspeellijsten te zoeken voor je stemming of activiteit.
- Could-have: Iets wat gebruikers prettig vinden, maar waarvan de afwezigheid geen doorslaggevend bezwaar is. Spotify zou gebaren gebruiken om van nummer te wisselen in plaats van knoppen.
- Won’t-have: Functies of initiatieven die jij, je belanghebbenden of je team tijdens sessies voor backlogverfijning of prioriteringsvergaderingen als nutteloos hebben beoordeeld.
Zoals je ziet, is MoSCoW een vrij eenvoudige techniek. En dat is een van de redenen waarom ik deze graag gebruik: de techniek is heel eenvoudig uit te leggen aan iedereen in de ruimte en hen ertoe aan te zetten deze ook te gebruiken bij het selecteren van taken met een lage of hoge prioriteit uit de lijst met items waaraan je werkt.
Kano
Dit is nog een eenvoudige techniek waarmee je de betreffende functies kunt bekijken vanuit het perspectief van de behoeften van je gebruikers. Hierbij deel je je functies in deze categorieën in:
- Basisbehoeften: De afwezigheid ervan is een reden voor de gebruiker om af te haken. In een hotelkamer zou het gaan om de aanwezigheid van schoon beddengoed op het bed.
- Prestatiebehoeften: Functies waarvan de hoeveelheid of aanwezigheid de tevredenheid van de gebruiker rechtstreeks verhoogt. Dat is het interieurontwerp van de hotelkamer of de aanwezigheid van was- of ontbijtdiensten.
- Behoeften die voor enthousiasme zorgen: De afwezigheid hiervan vermindert de tevredenheid niet. Maar hun aanwezigheid zal die zeker verhogen. Denk aan de schattige origami van een zwaan, gemaakt van handdoeken op je bed in de hotelkamer.
Hier is een grafiek die de relatie tussen deze typen functies en de tevredenheid van gebruikers in het Kano-model illustreert.
Kort samengevat is de productbacklog de takenlijst van het team, die de productmanager (of het productteam) opstelt en bijhoudt met behulp van uiteenlopende tools en technieken voor backlogbeheer.
Wat is een sprintbacklog?
Nu de aard van de productbacklog zelf duidelijk is, gaan we begrijpen wat de sprintbacklog inhoudt (tip: het heeft niets met sporten te maken.)
Scrum.org definieert de sprintbacklog als de deelverzameling van de productbacklog die het scrumteam heeft geselecteerd om tijdens de komende sprint af te ronden. Binnen het scrumraamwerk is dit een van de belangrijkste scrumartefacten waarmee het hele team werkt.
Zoals de definitie suggereert, is het kerndoel van de sprintbacklog om duidelijk de reikwijdte te definiëren van het werk waarop het team zich tijdens de sprint moet concentreren.
Het opstellen van de sprintbacklog gebeurt meestal tijdens de sprintplanningsvergadering. Hier zie je doorgaans de volgende activiteiten:
- De productmanager bepaalt het doel van de sprint.
- Het team begint met het selecteren van een haalbare lijst met opleveringen die kan helpen dit doel te bereiken.
- Het team splitst de gebruikersverhalen op in technische taken en maakt hiervan een inschatting.
- Ze bekijken hun capaciteit en snelheid uit eerdere sprints om te valideren dat de sprintbacklog haalbaar is.
In tegenstelling tot de productbacklog, waarvan de PM de enige eigenaar is, ligt de verantwoordelijkheid voor het opstellen en bijhouden van de sprintbacklog bij het scrumteam. Omdat zij degenen zijn die de taken uitvoeren die nodig zijn om de functies te bouwen, zijn zij het best in staat om de omvang en reikwijdte van de sprintbacklog te bepalen.
In tegenstelling tot veel andere scrumartefacten, die sommige teams misschien besluiten te negeren (dat is volkomen prima; je past scrum aan jouw team aan en niet andersom), lijkt de sprintbacklog het artefact te zijn dat bijna iedereen gebruikt. Daar zijn goede redenen voor. De sprintbacklog biedt je namelijk:
- Duidelijkheid over de reikwijdte: Het team heeft een goed begrip van het werk dat het tijdens de volgende iteratie moet uitvoeren.
- Meer focus: Met een duidelijke werkomvang en een scrummaster die zich verzet tegen alle pogingen om nieuwe taken aan de sprint toe te voegen, hoeft het team zich op niets anders te richten dan op de onderdelen in de sprintbacklog.
- Betere voortgangsregistratie: Omdat er geen onderdelen aan de sprintbacklog worden toegevoegd of eruit worden verwijderd, is het vrij eenvoudig om te zien hoe goed je team vordert richting het sprintdoel.
Wat het derde punt betreft: de meeste Agile-hulpmiddelen beschikken over ingebouwde rapportagehulpmiddelen voor sprints die de voortgang van je team automatisch voor je bijhouden. Een van de populairste rapporten hiervoor is de burndowngrafiek.
Deze grafiek bestaat uit twee lijnen die naar beneden lopen. De grijze lijn toont de hypothetische ideale voortgang van je team. De rode lijn toont daarentegen de werkelijke voortgang. Jira (het hulpmiddel dat in de schermafbeelding wordt getoond) meet deze lijnen op basis van het totale aantal resterende verhaalpunten dat je team moet voltooien. Wanneer iemand een taak sluit, daalt de rode lijn dus met een aantal dat gelijk is aan de geschatte verhaalpunten van die taak.
Een sprintbacklog opstellen en beheren
Het proces van het maken van een sprintbacklog begint met een productbacklog die nog niet is verfijnd. Product owners houden regelmatig sessies voor backlogverfijning (ook wel opschonen genoemd), waarin het team:
- De PM vragen stelt over het ontwerp en de vereisten om duidelijk te begrijpen wat het productteam van hen verwacht dat ze bouwen.
- Sommige punten in de vereisten ter discussie stelt als het veel tijd kost om ze te maken of tot technische problemen zal leiden.
- Voor elk item op de backlog het eigenaarschap toewijst aan het teamlid dat volgens hen het beste bij die specifieke taak past.
- De omvang van de taak of het verhaal inschat met behulp van een van de populaire technieken, zoals Fibonacci-getallen in combinatie met planning poker.
Ervan uitgaande dat het team voldoende taken voor de volgende iteratie heeft verfijnd, houdt het team een sprintplanningssessie waarin het zich vastlegt op een bepaald aantal taken uit de productbacklog. Op het moment dat het team zich daartoe committeert en de sprint begint, wordt deze groep taken de sprintbacklog.
Voor het beheren van de sprintbacklog biedt de Agile-methodologie ons verschillende hulpmiddelen, waaronder:
- Dagelijkse stand-ups waarin elk teamlid zijn voortgang aan het team toont en eventuele belemmeringen meldt die hen vertragen.
- Burn-up- en burn-downgrafieken die de algehele voortgang van het team visualiseren.
- Demobijeenkomsten aan het einde van de sprint waarin het team de resultaten van zijn werk aan het productteam presenteert en bruikbare feedback krijgt over het ontwerp en de functionaliteit van de functies die het heeft gebouwd.
Tot slot zijn er de retrospectieve bijeenkomsten. Ze helpen je niet rechtstreeks bij het beheren van je sprintbacklog, maar je kunt er de processen bespreken die de kwaliteit en efficiëntie van het beheer ervan zullen verbeteren.
Belangrijkste verschillen tussen productbacklogs en sprintbacklogs
Om de verschillen tussen deze ogenschijnlijk vergelijkbare concepten beter te begrijpen, geef ik eerst een overzicht naast elkaar van de verschillen en leg ik daarna elk element uitgebreider uit.
Hoewel het overzicht zelf gemakkelijk kan uitleggen waarin ze verschillen, heb je misschien nog vragen over specifieke aspecten. Daarom neem ik ze één voor één met je door.
Tijdsspanne: Productbacklogs vertegenwoordigen je middellange- tot langetermijnplan, omdat ze je productroadmap en visie weerspiegelen. De planningshorizon kan daarom variëren van meerdere sprints tot een paar jaar.
Sprintbacklogs hebben daarentegen een zeer korte tijdsspanne, omdat ze de items vertegenwoordigen die je team in de volgende sprint wil opleveren (die doorgaans 1-4 weken duurt).
Eigenaarschap: Zoals we al hebben genoemd, is de eindverantwoordelijke voor de productbacklog iemand uit het productteam (meestal de product owner die aan dat team is toegewezen). Het Scrum-team kan bijdragen aan de backlog, maar kan dat alleen via de PM doen.
De situatie is anders bij de sprintbacklog. De enige manier waarop een PM hier invloed op kan uitoefenen, is door het sprintdoel vast te stellen. Afgezien daarvan is het het Scrum-team dat de bevoegdheid heeft om de sprintbacklog te maken en te beheren.
Detailniveau: Omdat de elementen in een productbacklog het werk van meerdere kwartalen of zelfs jaren kunnen vertegenwoordigen, is het niet realistisch dat de PM elk element gedetailleerd beschrijft. Ik raad dit zelfs sterk af, omdat er altijd een kans bestaat dat je uiteindelijk veel functies uit de backlog verwijdert en het zonde van de tijd zou zijn om ze nauwgezet te beschrijven.
Meestal heb je een hoog detailniveau voor de elementen met de hoogste prioriteit en een globale beschrijving voor al het overige.
Om verhalen echter in de sprintbacklog op te nemen, moeten ze alle beschikbare details bevatten. Anders zal het Scrum-team weigeren de verhalen te implementeren als het niet duidelijk begrijpt wat er van hen wordt verwacht.
Doel: De productbacklog is de “tussenpersoon” tussen zeer vage strategische plannen en zeer specifieke technische implementatiedetails. De backlog dient als hulpmiddel om je strategische plannen vorm te geven als een takenlijst.
Sprintbacklogs zijn daarentegen zeer tactisch van aard en zijn bedoeld om het team een duidelijk kortetermijnactieplan en een heldere scope te bieden.
Flexibiliteit: Productbacklogs zijn levende documenten die voortdurend veranderen. Gezien hun langetermijnkarakter moeten ze veranderen op basis van nieuwe prioriteiten, feedback van gebruikers en marktomstandigheden, zodat je product levensvatbaar blijft.
Sprintbacklogs zijn daar het tegenovergestelde van. Hoewel ik je sterk aanmoedig om de productbacklog voortdurend te ontwikkelen, is het aanpassen van elementen in een sprintbacklog absoluut af te raden, omdat je uiteindelijk alle toezeggingen en plannen van je team zou ondermijnen.
Hoe de productbacklog en sprintbacklog samenwerken
Zoals gezegd is de sprintbacklog de nauwkeurigere en verduidelijkte subset van de productbacklog. Je beschouwt deze nog steeds als onderdeel van de backlog totdat je huidige sprint is afgelopen. Daarna verlaten de voltooide stories de backlog en komen de onvoltooide stories opnieuw bovenaan de prioriteitenlijst te staan.
Wat betreft de stroom van functies tussen deze twee backlogs, vul je de sprintbacklog dus niet alleen met items uit de productbacklog, maar kan het omgekeerde ook gebeuren.
Ongeacht in welke richting de stories gaan, een soepele overdracht is essentieel. Dit zijn de punten waar je volgens mij op moet letten:
- Alles wat aan de sprintbacklog wordt toegevoegd, moet openstaande vragen voor het scrumteam bevatten. Anders word je een blokkade voor de voortgang van de sprint. De beste manier om dit te beheren, is samen met je team een Definitie van gereedheid-lijst (DoR) op te stellen en deze te volgen.
- Alles wat aan de sprintbacklog wordt toegevoegd, moet schattingen bevatten. Anders zijn de toezeggingen en plannen van je team onjuist. Het zou ook lastig zijn om burndowndiagrammen te gebruiken om de voortgang te bewaken.
- Vraag het team bij het opstellen van de sprintbacklog altijd duidelijk of het zich prettig voelt bij de werklast. Mensen hebben de neiging zichzelf te veel werk op te leggen en eindigen met half afgemaakte sprints.
- Wanneer je aan het einde van de sprint onvoltooide items uit de sprintbacklog haalt, moet je dit altijd opvolgen tijdens de retrospectieve bijeenkomst. Zo kun je inefficiënties in het proces vinden en elimineren.
Over het geheel genomen ziet het volledige proces er als volgt uit.
Naast tips om deze twee met elkaar te verbinden, help ik je graag om beide goed te beheren met enkele beste werkwijzen uit mijn ervaring.
Beste werkwijzen voor het beheer van de productbacklog
Het beheren van een productbacklog kan prettig of verschrikkelijk zijn, afhankelijk van hoe goed je deze beheert. Dit is wat ik doe op basis van jarenlange ervaring:
- Voortdurend opschonen: Vind de moed om items uit de backlog te verwijderen waarvan het zeer onwaarschijnlijk is dat ze in ontwikkeling worden genomen.
- Communicatie met belanghebbenden: Houd regelmatig prioriteringsbijeenkomsten op hoofdlijnen met je belanghebbenden. Zo sluit het plan dat zij voor ogen hebben aan op wat er in jouw backlog staat.
- Afzonderlijke lijst voor items met een onzekere toekomst: Soms kom jij of een belanghebbende met ideeën die misschien wel en misschien niet worden gebouwd. Om te voorkomen dat ze je backlog onoverzichtelijk maken, bewaar je ze ergens in een afzonderlijke lijst. Voeg ze pas aan de backlog toe wanneer je weet dat je ze gaat bouwen.
Tot slot raad ik je aan gebruik te maken van de vele tools en sjablonen voor productbacklogs die beschikbaar zijn, om het creatieproces te versnellen. Hier vind je een hele reeks van ClickUp die je kunt gebruiken.
Als je meer wilt lezen over beste werkwijzen voor producten, raad ik je aan onze speciale gids hierover te bekijken.
Beste werkwijzen voor het beheer van de sprintbacklog
De sprintbacklog vertegenwoordigt de omvang van een specifieke increment. Daarom verschillen de tips voor goed beheer ervan enigszins:
- Vermijd overplanning: Mensen zijn slecht in het inschatten van hun eigen capaciteiten. Als je team zich vastlegt op een aanzienlijk grotere sprintbacklog dan voorheen, wil je hen helpen een paar items eruit te verwijderen.
- Pak blokkades dagelijks aan: In mijn loopbaan, waarin ik honderden sprints heb meegemaakt, heb ik nog nooit een volledig soepele sprint gezien. Blokkades zullen altijd ontstaan. En als je ze niet onmiddellijk aanpakt, keldert de kans dat je de sprint voltooit. Let daarom goed op wat je team tijdens de dagelijkse stand-ups meldt.
- Gebruik gespecialiseerde tools: Het internet staat vol software die is ontwikkeld om de efficiëntie en effectiviteit van je Agile processen te verbeteren. Maak daar gebruik van.
Wat betreft het laatste punt: hier zijn enkele tools met alle onmisbare functies die je kunt overwegen te gebruiken.
Atlassian Jira: Agile tool met uitgebreide functies voor complexe workflows en grote teams.
Trello: Lichtgewicht tool voor taakbeheer met Agile plug-ins (Kanban en Scrum), die het meest geschikt is voor kleine startupteams.
Monday.com: Dit houdt het midden tussen Jira en Trello. Het biedt veel functies, maar ondersteunt ook eenvoudig lichtgewicht processen en kleine teams.
Bekijk voor meer informatie ook onze lijst met de beste tools voor productmanagement.
Veelvoorkomende valkuilen en uitdagingen van backlogbeheer
Ik ben de tel kwijtgeraakt van de erbarmelijke mislukkingen die ik in de loop van mijn carrière heb meegemaakt bij het beheren van mijn backlogs. Hoewel fouten maken onvermijdelijk is (zo leer je), wil ik toch een paar belangrijke fouten benoemen in de hoop dat jij ze zult vermijden (in tegenstelling tot ik).
Denken dat je alles weet: Dit geldt vooral wanneer je junior bent (hallo, Dunning-Krugereffect). Je leest een paar artikelen over het beheren van backlogs en denkt dat je het beter kunt dan wie dan ook. Dat leidt bijna altijd tot een grote blunder. Dus als er meer ervaren productmanagers in de buurt zijn, aarzel dan niet om hun hulp te vragen. Je kunt ook de voorbeelden bekijken van productbacklogs die goed zijn uitgevoerd.
Stoppen met leren: De wereld van Agile ontwikkelt zich snel. Als je stopt met leren over nieuwe werkwijzen en hulpmiddelen, krijg je te maken met problemen waarvoor al vernieuwende oplossingen bestaan. Schrijf je dus in voor cursussen of webinars over Agile en abonneer je op onze nieuwsbrief voor veel bronnen en handleidingen over productmanagement.
Denken dat PMs geen deel uitmaken van het Agile-team: Als je denkt dat PMs niets te maken hebben met de items binnen de sprint, zul je waarschijnlijk in de meeste van je sprints falen. Tijdens de implementatie van gebruikersverhalen ontstaan altijd productgerelateerde vragen en verzoeken om verduidelijking. Hoe sneller je die oplost, hoe beter het resultaat tijdens de sprintreview zal zijn.
Alles is een prioriteit en de deadline was gisteren: Dit staat ook wel bekend als “de CEO-ziekte” en is een teken dat je backlog geen prioriteiten heeft. Een eenvoudige manier om dit te beperken is de moed te hebben om tegen je CEO te zeggen: “Nee, we hebben de capaciteit niet. Zeg me alsjeblieft welke belangrijker is.” Geloof me, de meeste CEO’s zullen naar je luisteren en je een duidelijke prioriteit geven.
