Menu

Scrum-artefacten: Product Backlog, Sprint Backlog en Product Increments

  • Hoofd
  • Andere
  • Scrum-artefacten: Product Backlog, Sprint Backlog en Product Increments

scrum artifacts product backlog

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Inleiding tot Scrum-artefacten:

In de vorige artikelen van deze serie maakten we kennis met agile en de verschillende agile methodologieën ​We hebben ook geleerd hoe de verschillende methodologieën op hun eigen manier verschillen.

In onze laatste tutorial gingen we in op de details van Scrum waar we het Scrum-rollen zoals Product Owner, Scrum Master en het scrumteam en zagen wat hun individuele verantwoordelijkheden waren.

In deze tutorial gaan we verder met Scrum en gaan we verder in op de details over de verschillende scrum-artefacten.

Scrum-artefacten

Wat je leert:

Verschillende Scrum-artefacten

3 soorten scrum-artefacten zijn onder meer:

  • Productachterstand
  • Sprint backlog en
  • Productstijgingen

Nu zullen we zien wat deze termen betekenen en hoe we deze artefacten kunnen maken.

Scrum Artefacten-typen

Productachterstand

Simpel gezegd: een product backlog is een lijst met alle dingen die nodig zijn in het product. Het is het laatste document waarnaar het scrumteam verwijst voor alles wat met het product te maken heeft. Het is een geordende lijst met items die eigendom is van de Product Owner (PO).

De PO is verantwoordelijk voor het maken, onderhouden en prioriteren van deze lijst. De PO's gebruiken deze product backlog om aan de scrumteams de belangrijkste vereisten uit te leggen die tijdens de sprint moeten worden gedaan.

De items in deze lijst kunnen al dan niet in een technische taal zijn opgesteld. Het kan zelfs een lekentaal zijn, maar het moet alle productvereisten en de bijbehorende wijzigingen bevatten. Het hebben van een productachterstand betekent ook niet dat het scrumteam alleen dit artefact hoeft te volgen.

Ze kunnen hun eigen gedetailleerde artefacten maken, maar die zullen de productachterstand niet tegenspreken of vervangen. Ze zullen eerder in lijn zijn met de vereisten van de productachterstand.

Hieronder ziet u een voorbeeld van hoe een typische productachterstand eruit kan zien:

VerhaalSchattingPrioriteit
Ik wil inloggen4een
Ik wil uitloggentweetwee
Ik wil het wachtwoord wijzigeneen3
Ik wil het adres bijwerken34
Ik wil een nieuw telefoonnummer thuis toevoegeneen5

Dit brengt ons bij de vraag, hoe creëer je een goede product backlog?

Een productachterstand zou idealiter de onderstaande regels moeten volgen:

(i) Het moet prioriteit krijgen - De items in de product backlog moeten worden besteld volgens hun prioriteit. Deze prioriteit kan door de PO en het scrumteam samen worden bepaald. De prioriteitsfactoren kunnen elk soortgelijk voordeel zijn van het verhaalpunt, de inspanning die betrokken is bij de creatie, complexiteit, klantprioriteit enz.

Het helpt het team om te begrijpen wat als eerste moet worden geleverd.

(ii) Het moet worden geschat - De verhalen moeten altijd worden geschat volgens de overeengekomen definitie, wat dat ook mag zijn. Dit kan ook worden gebruikt voor het stellen van prioriteiten.

(iii) Het moet van hoog niveau zijn - De verhalen in de product backlog zijn bedoeld om van hoog niveau te zijn en mogen niet op de details ingaan. Het creëren van gedetailleerde gebruikersverhalen volgens de vereiste is aan het scrumteam en niet aan de PO.

(iv) Het moet dynamisch zijn - De productachterstand is geen definitief statisch document. Het moet opnieuw worden bekeken aangezien de PO input ontvangt van het scrumteam en de eisen van de klant steeds duidelijker worden. De documentvereisten worden dus niet meteen bevroren, omdat er aanvullingen / weglatingen / wijzigingen worden verwacht naarmate het project vordert.

Het laatste punt is het meest relevante. Het doel van een product backlog is om een ​​actieve bron van vereisten te zijn. Het wordt in het begin niet aangemaakt en vervolgens op een opslaglocatie bewaard.

In plaats daarvan is het bedoeld om keer op keer te worden gedeeld terwijl de veranderingen blijven komen. Er kunnen nieuwe vereisten komen naarmate de voortgang wordt geboekt en dat kan ook de prioriteit van de backlog-items veranderen. Er zullen situaties zijn waarin een nieuwe vereiste afhankelijk is van een ander item in de backlog, zodat de itemprioriteit mogelijk opnieuw moet worden geschud.

Of er kan een kritisch gebruikersverhaal zijn dat misschien eerst moet worden geïmplementeerd omdat de klant dat eerder wil zien dan de anderen, ook al heeft het misschien niet de hoogste prioriteit volgens de factoren die zijn bepaald door de PO en het scrumteam.

De productachterstand is dus een geordende lijst met zakelijke vereisten die eigendom zijn van de PO en die keer op keer op tijd worden bezocht naarmate het project vordert.

Sprint achterstand

U herinnert zich misschien dat de scrumteams in korte iteraties van 2 tot 4 weken werken, een sprint genaamd. Tijdens deze sprints identificeert het scrumteam de items van de productachterstand die door de PO is gecreëerd en die ze willen leveren als onderdeel van de volgende iteratie. De items die het scrumteam selecteert om aan te werken, worden onderdeel van de sprint-backlog.

Zo beslissen ze welke functionaliteiten er zullen zijn in de volgende iteratie van het product. Het scrumteam is degene die beslist wat er in de sprint backlog terecht komt, aangezien zij degenen zijn die eraan gaan werken.

Zij zijn dus degenen die de moeite moeten inschatten die nodig zijn om die verhalen te implementeren en te beslissen hoeveel ze kunnen opleveren.

Het team kiest niet alleen de items uit de productachterstand om aan te werken, maar ze maken ook een schatting van hoeveel tijd het zal kosten om die functionaliteit te ontwikkelen. Ze dragen ook bij aan de gebruikersverhalen op hoog niveau door gedetailleerde taken te maken die nodig zijn om het sprintdoel te bereiken.

gratis dvd-ripsoftware voor Macs

Het scrumteam kan tijdens de sprint ook de sprint backlog blijven updaten als dat nodig is, maar alleen het scrumteam kan de sprint backlog aanpassen.

Een typische Sprint Backlog ziet er uit zoals hieronder weergegeven.

Sprint achterstand

Het team kan dit idealiter één keer per dag updaten en de scrummaster kan deze informatie gebruiken om een ​​sprint burndown chart te maken. Deze burndown-grafiek helpt het team te zien hoeveel werk er nog over is voor de sprint en het team kan hun werk dienovereenkomstig plannen. Ze kunnen zelfs taken toevoegen of verwijderen, indien nodig.

Enkele best practices bij het creëren van een sprint-backlog kunnen zijn:

# 1) Groepsbeslissingen nemen - Het mag niet de scrummaster of een ander lid van het scrumteam zijn die de achterstand bepaalt. Het zou eerder het hele team moeten zijn om te beslissen welke items in de sprint-backlog moeten worden opgenomen en hoe ze daarvoor moeten plannen.

Elk lid van dit multifunctionele team brengt zijn eigen vaardigheden in en het is essentieel dat we hun ervaring gebruiken om de best mogelijke achterstand te creëren.

# 2) Wijs geen taken toe - Wijs nooit taken toe aan de teamleden, aangezien het meerdere keren is herhaald in de agile literatuur. Een scrumteam hoort zelfvoorzienend te zijn en ze moeten weten hoe ze hun werk zelf moeten organiseren.

Dus in plaats van werk toe te wijzen, moeten we het team zelf werk laten kiezen en onderling beslissen hoe ze verder willen gaan.

# 3) Definitie van klaar - Het moet niet alleen worden overeengekomen door de belanghebbenden, maar moet ook op alle punten duidelijk zichtbaar worden gemaakt voor het team wanneer ze een beslissing moeten nemen over de sprintdoelen. Dit zal dienen als een herinnering aan wat er precies moet gebeuren voordat ze een werkend verzendbaar product kunnen leveren.

# 4) Blijf de achterstand bijwerken - Het is absoluut noodzakelijk dat naarmate de sprint evolueert, het team een ​​beter begrip krijgt en daarom moeten ze de sprintachterstand dienovereenkomstig bijwerken om ook dit grotere begrip weer te geven. Het mag op geen enkel moment een statisch document worden.

# 5) Voeg een taak toe - De taak hoeft niet alleen verband te houden met codering, maar het kan ook essentieel zijn om een ​​verzendbaar product te leveren. Vermeld daarom dergelijke taken ook in de backlog.

Productverhogingen

Dit brengt ons bij het laatste scrumartefact, namelijk de productverhogingen. Zoals gedefinieerd door de scrumgids, is een increment de som van alle Product Backlog-items voltooid tijdens een Sprint en de waarde van de incrementen van alle voorgaande Sprints. Zoals we inmiddels goed weten, is Scrum een ​​iteratief proces.

Het resultaat van elke iteratie is deze productstapeling en elke dergelijke productstap helpt het team een ​​stap dichter bij het leveren van het eindproduct te komen.

Dit betekent dat wat het resultaat van de sprint ook was, een increment is. Om het resultaat als een increment te beschouwen, moet het natuurlijk eerst voldoen aan de vooraf gedefinieerde definitie van done, d.w.z. het eindresultaat moet een bruikbaar product zijn dat kan worden 'verzonden'.

Het kan worden gecontroleerd, gebruikt en getest om er zeker van te zijn dat het inderdaad 'gedaan' is volgens de definitie en als de Product Owner dat wenst, kan het ook worden vrijgegeven om live te gaan.

Het belangrijkste om dit productincrement te leveren, is om een ​​gedeeld begrip te hebben van de 'definitie van gedaan' die door iedereen wordt begrepen.

Het scrumteam mag nooit twijfelen of wat ze doen, wordt geaccepteerd of niet. Als er enige twijfel bestaat, moet de definitie van done voldoende compleet zijn om hen te begeleiden bij het verder gaan. Alleen op basis van deze definitie bepaalt het scrumteam hoeveel product backlog-items er voor de sprint moeten worden gepickt.

Dit is het minimum dat wordt verwacht van de sprint.

Gevolgtrekking

In deze tutorial hebben we begrepen wat de 3 scrum-artefacten zijn, die de eigenaar zijn, samen met enkele van de best practices die ons zouden helpen artefacten van betere kwaliteit te maken. In onze volgende tutorials van deze serie zullen we de Scrum-evenementen bespreken en zien hoe we die evenementen kunnen uitvoeren.

In onze aanstaande tutorial over ‘Scrum Evenementen ​ ’We zullen elk van de Scrum-evenementen in detail bespreken!

PREV-zelfstudie ​ VOLGENDE zelfstudie

Aanbevolen literatuur

^