User story en PBI

Deze blog geeft antwoord op de vraag: wat is het verschil tussen een User story en een Product Backlog Item?

User story

Een User story is de omschrijving van een klantvraag en daarmee onderdeel van een Product Backlog Item (PBI). Zo’n User story kan je formuleren aan de hand van dit format:

• Als <rol>
• Wil ik <doel>
• Zodat <opbrengst>

Voorbeeld User story:

Als Scrum Master wil ik dat het Scrumteam User Stories gebruikt zodat ieder PBI een heldere omschrijving heeft en het Development Team beter weet wat er wordt verwacht.

Dit format helpt om na te gaan wie er bij dit PBI gebaat is, wat het doel ervan is én wat het oplevert.

Product Backlog Item

Eén item op de Backlog bevat meer dan alleen een User story. Tien onderdelen van een PBI:

1. Titel
   Een korte, pakkende titel die de lading dekt voor wat deze PBI oplevert. Met andere woorden: het Scrumteam én stakeholders moeten snappen wat dit PBI inhoudt aan de hand van de titel.
2. Omschrijving
   De description van een PBI, in de vorm van een User story! Naast die tekstregels zoals het format dat hierboven is toegelicht, kan je hier meer informatie in kwijt. Denk bijvoorbeeld aan de scope, een toelichting waarom bepaalde keuzes zijn gemaakt, wie de stakeholder voor dit PBI is, eventueel een deadline en technische impact. Kortom: alles dat nodig is voor een helder omschrijving.
3. Acceptatie Criteria
   Anders dan de D.O.D. die voor álle PBI’s geldt, gaan de Acceptatie Criteria specifiek over één PBI. Het zijn de kaders van dit PBI die verhelderen wat de vereisten zijn om aan de verwachting van de gebruiker te voldoen. De Product Owner stelt deze op en stemt ze af met het Development Team.
4. Taken
   Zie mijn vorige blog “Van Epic naar Task” voor meer informatie over taken.
5. Links naar Epics en Features
   Bij Backlog Management tools zoals TFS en Jira, kan je PBI’s linken aan bovenliggende niveaus. Als het PBI op de juiste plek en manier wordt aangemaakt, ontstaat deze (hiërarchische) link automatisch. Zie wederom mijn vorige blog voor meer hierover.
6. Effort
   Door middel van Planning Poker kan het Development Team relatief schatten en zo de effort bepalen in story points. Dit is een cijfer voor complexiteit, met factoren hoeveelheid werk, moeilijkheid, ervaring, afhankelijkheden en onzekerheid. Aangezien effort gaat over hoeveel moeite het kost voor het Development Team om dit op te leveren, gaan de Product Owner en stakeholders hier níet over!
7. Business Value
   De (klant)waarde dat het PBI oplevert, wordt bepaald door de Product Owner in samenspraak met de stakeholders. Dit kan op een vergelijkbare manier als hoe de effort wordt bepaald, maar dan via Value Poker. Aangezien Business Value letterlijk gaat over de waarde die de business (klant/gebruiker) hieraan geeft, gaat het Development Team hier níet over!
8. State
   Een PBI kan een bepaalde staat hebben. Mijn laatste Scrumteams gingen hier op deze manier mee om:
   • New: voor nieuwe PBI’s op de backlog, die nog niet een van de volgende fases hebben bereikt.
   • Approved: het PBI is refined en compleet met deze 10 onderdelen. Dat betekent dat het is goedgekeurd om deze in een volgende Sprint op te kunnen nemen.
   • Committed: de staat zodra een approved PBI bij de Sprint Planning wordt opgenomen in de Sprint.
   • Done: zodra het PBI tijdens een Sprint volledig volgens de D.O.D. en Acceptatie Criteria is afgerond.
9. Tags
   Optioneel kan je gebruik maken van Tags. Dit kán helpen voor beter Product Backlog Management met meer overzicht. Bijvoorbeeld om PBI’s over hetzelfde thema te clusteren, of als je dat onderwerp niet in de titel kwijt kan. Voorbeelden van hoe mijn teams deze hebben gebruikt: onderhoud, optimalisatie, vermarkting en vernieuwing.
10. Attachments
    Bijlagen die de User story verhelderen en die te groot zijn om in de omschrijving toe te voegen. Denk aan bestanden, mails en screenshots.

INVEST

Ieder PBI voldoet aan de acroniem INVEST:

• Independent
  Geen afhankelijkheden met andere PBI’s, dus losstaand releasable binnen een Sprint.
• Negotiable
  Letterlijk onderhandelbaar maar ook veranderlijk. Het Scrumteam moet kunnen overleggen wat hier wel en niet bij komt kijken en “hóe” de “wat” wordt geleverd.
• Valuable
  Het moet duidelijk zijn wat de waarde voor de gebruikers is. Een Product Owner kan samen met stakeholders de Business Value van elk PBI bepalen.
• Estimable
  Een PBI moet in te schatten zijn. Het Development Team bepaalt hiervoor de effort.
• Small
  Opgeknipt en klein genoeg om binnen een Sprint op te leveren. En dan nog wél waarde toevoegen!
• Testable
  Het PBI moet te testen zijn en voldoen aan de D.O.D. en Acceptatie Criteria.

Product Backlog Management

Hoe krijg je een PBI goed en compleet op de backlog? Hieronder een voorbeeld van een Product Backlog Item in TFS en in welke velden de verschillende (genummerde) onderdelen zich bevinden. Hopelijk draagt dit bij aan optimaal Product Backlog Management!

Een PBI in TFS