De Product Backlog is de enige bron van taken die door het Scrum Team worden uitgevoerd. Het is een lijst van geplande Productfunctionaliteit en verbeteringen. De vorm ervan is veranderlijk en niet alle taken die in de Product Backlog zijn opgenomen, zullen worden voltooid. Het evolueert tijdens discussies met Stakeholders. Het wordt ook voortdurend verbeterd. Dit betekent dat hoe dichter bij de deadline, hoe gedetailleerder een taak wordt.
De Product Backlog is de grootste van de Scrum Artefacten. Het weerspiegelt de status van het werk aan een Product met betrekking tot het Productdoel. Aan de andere kant, wanneer het werk aan een Product is voltooid, wordt de Backlog een complete lijst van de taken die door het Scrum Team zijn uitgevoerd om het Product te creëren. Het bevat echter geen gedetailleerde technische oplossingen.
De Product Backlog wordt gecreëerd tijdens de vergaderingen van de Product Owner met Stakeholders. De Product Owner is de enige eigenaar en de persoon die verantwoordelijk is voor deze bron van taken.
De zakelijke taal kenmerkt de vermeldingen in de Product Backlog. Met andere woorden, ze beschrijven de waarde van het Product vanuit het perspectief van de Stakeholders.
Taakomschrijvingen die in de takenlijst zijn opgenomen, moeten samenhangend en duidelijk zijn. Ze bevatten functies en verbeteringen van het Product die meestal worden gepresenteerd in de vorm van User Stories, waaraan we een aparte vermelding wijden. Hier zullen we alleen vermelden dat dit beschrijvingen zijn van gedeeltelijke functionaliteiten van het product die de vragen over de volgende onderwerpen beantwoorden:
De volgorde van taken die in de Product Backlog zijn opgenomen, verandert naarmate het Product zich ontwikkelt. Terwijl eraan wordt gewerkt, vormt en verbetert het Scrum Team de functionaliteiten. Bij het tegenkomen van obstakels stellen de geïmplementeerde acties iedereen in staat om na te denken over en toekomstige adequate oplossingen te definiëren, en deze zullen ook veranderen in overeenstemming met onvoorziene verdere obstakels. Daarom is er geen duidelijke en gedefinieerde volgorde van acties, alles is veranderlijk. Verbetering van de Product Backlog is gericht op de continue bijwerking en voorbereiding voor de volgende taken. Om deze reden is het continu.
Taken met een verre deadline zijn doorgaans grote, generieke geheel. Hun beschrijving bevat geen details, maar alleen een schets van de functionaliteit die moet worden gerealiseerd. Het is ook mogelijk om taken onder hen te vinden die nooit zullen eindigen.
Vermeldingen in de Product Backlog kunnen alternatieve oplossingen presenteren. En ook de ideeën van de Klant die verouderd, onrendabel of om een andere reden nooit de implementatiefase ingaan. Daarom wordt de Product Backlog soms gekscherend de “wensenlijst van de Klant” genoemd.
Een andere reden voor veranderingen in de vorm van de Product Backlog is het herdefiniëren van oplossingen. Soms blijkt dat een bepaald probleem al is opgelost bij het creëren van een andere productfunctionaliteit. Of de verwachte functionaliteit is overbodig geworden door veranderingen in andere oplossingen.
Een van de basisactiviteiten tijdens de verbetering van de Product Backlog is het opdelen van de taken die in de Product Backlog zijn opgenomen in delen. Dankzij dit wordt de algemene schets van functionaliteit gepresenteerd in de vorm van kleinere, meer gedetailleerde en precies gedefinieerde eenheden.
Taken die voor een dichterbij komende implementatie zijn ontworpen, worden gedetailleerder. Ze worden ook kleiner, met details van oplossingen. Details komen naar voren tijdens de ontwikkeling van het Product. En dankzij de kennis van de huidige staat van het Product en de huidige verwachtingen van Stakeholders, aanvult de Product Owner de aankomende taken met hun beschrijving, volgorde en grootte. Vervolgens selecteert hij de best beschreven taken voor de volgende Sprint Backlog.
Tijdens het werken aan een Product, wijzigt en detailleert de Product Owner de Product Backlog in samenwerking met het Ontwikkelteam. Volgend op de suggesties van de Product Owner, selecteert het team tijdens de Sprint Planning functies om te implementeren vanuit de Product Backlog. Deze worden vervolgens verplaatst naar de Sprint Backlog en verdeeld in taken die moeten worden voltooid. De taken die naar de Sprint Backlog zijn verplaatst, worden in technische taal beschreven, wat het meest nuttig is voor Ontwikkelaars.
Taakgrootte is een belangrijke maatstaf vanuit het perspectief van het Ontwikkelteam. De juiste schatting ervan wordt vooral kritisch wanneer User Stories van de Product Backlog naar de Sprint Backlog worden geselecteerd.
Het Ontwikkelteam leert in de loop van de tijd om de tijd en inspanning die nodig zijn om een specifieke User Story te voltooien, correct te schatten. Dit wordt uitgedrukt in dagen, manuren of Story Points en biedt een schatting van een waarde die Team Velocity wordt genoemd.
De Product Backlog is een voortdurend verbeterde lijst van taken die leiden naar het Productdoel. De inhoud van de Product Backlog wordt meestal uitgedrukt in de vorm van User Stories. En hoe korter de tijd die resteert om een taak te voltooien, hoe:
Het Scrum Team zorgt voor de taken. De Product Owner beheert en wijzigt de Product Backlog.
Als je onze inhoud leuk vindt, sluit je dan aan bij onze drukke bijengemeenschap op Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Als projectmanager is Caroline een expert in het vinden van nieuwe methoden om de beste workflows te ontwerpen en processen te optimaliseren. Haar organisatorische vaardigheden en haar vermogen om onder tijdsdruk te werken, maken haar de beste persoon om ingewikkelde projecten werkelijkheid te laten worden.
Bedrijven worstelen met het beheren van een enorme hoeveelheid inhoud die online wordt gepubliceerd, van…
In het tijdperk van digitale transformatie hebben bedrijven toegang tot een ongekende hoeveelheid gegevens over…
Wist je dat je de essentie van een meeruurs opname van een vergadering of gesprek…
Stel je een wereld voor waarin jouw bedrijf boeiende, gepersonaliseerde video's kan maken voor elke…
Om het potentieel van grote taalmodellen (LLM's) volledig te benutten, moeten bedrijven een effectieve aanpak…
In 2018 was Unilever al begonnen aan een bewuste reis om automatisering en augmentatie in…