1. Backlog refinement ⚒️ Flashcards
What is backlog refinement (meeting)?
Wanneer een team samen gaat zitten om de product backlog na te kijken, te updaten en op te schonen. Probeer altijd de hoeveelheid van refined product backlog items voor de duur van 2 sprints te hebben. Er mogen stakeholders bij refinement aanwezig zijn.
Voor de refinement sessie, schoont de PO de product backlog op en geeft initiële prioriteit, die kan veranderen tijdens refinement sessie.
Wat is de definition of ready, hoe volstaat dit tot refinement?
Definition of Done (DoR) zijn van te voren afgesproken criteria waarin een product backlog item aan moet voldoen, om op de sprint te komen.
Product backlog item moet bijvoorbeeld een user story hebben die goed geschreven is, acceptatie criteria, small enough to fit in the sprint, etc.
Definition of Ready is net als security bij een nachtclub, hij laat alleen mensen binnen die voldoen aan de verwachting. Gebruik het echter meer als guideline, niet als strikte regels
Wat zijn user stories?
Een user story is een informele, algemene uitleg van software features geschreven van het perspectief van de eind gebruikers. Het doel is om onder woorden te brengen hoe een feature waarde zal brengen voor de gebruiker.
De kern van agile software development is de gebruiker eerst plaatsen, de user story zorgt ervoor dat de gebruiker in het middelpunt staat.
User stories zijn een paar zinnen, in simpele taal die een bepaalde uitkomst beschrijven. Ze gaan nog niet in heel veel detail.
User stories zijn meestal op zelfde manier geschreven:
“As a [persona], I [want to], [so that].”
- As a [persona]: Voor wie maak je het? Maak het specifiek mogelijk, wie is je persona? Het team moet begrijpen wie max is.
- Wants to: Beschrijf wat ze willen bereiken, niet de software of features die nodig zijn. Beschrijf niks van de UI, maar het doel
- So that: Welke voordeel wilt de gebruiker bereiken, welk probleem willen ze oplossen
Wat zijn acceptatie criteria?
Acceptatie criteria focussen niet op hoe een oplossing is bereikt, maar meer of wat er gebeurt.
Bijvoorbeeld: Users can pay with google Pay or Apple Pay at checkout.
Het focust niet op hoe je dit moet doen, install a Wordpress plugin that allows you to create a check out page.
Het is aan het scrum team op te beslissen HOE ze acceptatie criteria voldoen.
Gebruik het volgende template:
Given (some given context or precondition), when (I take this action), then this will be the result
A Checklist for Writing Acceptance Criteria
- Clear to everyone involved
- Can be tested or verified
- Either passes or fails (cannot be 50% completed, for example)
- Focus on the outcome, not how the outcome is achieved
- As specific as possible (fast page load speed vs. 3-second page load speed)
Conclusie:
- Given that: geef context, Ik ben een nieuwe gebruiker, ik heb correct inlog informatie ingevuld, ik ben ingelogd
- When: de actie die je doet, wanneer je probeert in te loggen, wanneer je je informatie invult, wanneer ik op login klik
- Then: resultaat, toon error bericht, toon verschillende product opties, toon het dashboard, toon success bericht
Waar staat “INVEST” voor in relatie met user stories?
Het is een lijst van criteria voor hoge kwaliteit user stories.
I - Independant (of other stories), doesnt mean unrelated. Independant to their sequence
N - Negotiable ( not a specific contact for features)
V - Valuable (or vertical)
E - Estimable (to a good approximation)
S - Small (so as to fit within an iteration)
T - Testable (in principle)
The higher on the PO, EST more important, the lower the more INV
Wat betekent een user story die verticaal is, dus een verticale slice
De term “verticaal” in de context van user stories verwijst naar het idee dat elke story een volledige functie of waarde levert die door alle lagen van het systeem snijdt, van de gebruikersinterface (UI) tot aan de database en back-end logica. Dit staat in contrast met een “horizontale” benadering, waarbij taken zijn verdeeld op basis van technische lagen of disciplines, zoals alleen werken aan de database of alleen aan de UI zonder een eindgebruiker waarde te leveren.
Voorbeeld:
Registratie:
- UI: Een formulier waar de gebruiker persoonlijke gegevens invult.
- Business Logica: Validatie van gegevens, zoals het controleren op een uniek e-mailadres.
- Database: Opslaan van gebruikersgegevens in de database.
- Beveiliging: Zorgen voor veilige opslag van wachtwoorden en persoonlijke informatie.
Waar begin je precies met complexe problemen?
De aanpak van je probleem, product backlog item hangt af van het soort probleem. Om de complexity van een probleem te onderscheiden gebruiken we het Cynefin framework.
Splits problemen in vier soorten, Complex, Complicated, Clear and Chaotic.
Complicated and clear, je weet oorzaak en gevolg van te voren, je kunt plannen maken.
Aan de lunkder zijde kun je niet voorspellen, dit zijn problemen die veranderen wanneer je het probeert op te lossen.
According to Cynefin, hoe onderscheid je de verschillende soorten ‘problemen’?
- Clear problems - Eerder mee gewerkt, standard procedures, je weet oorzaak en gevolg al
- Complicated problems - Je weet oorzaken en hoe het werkt, maar expertise en analyse is nodig. Gedetailleerd project plan is de oplossing
- Complexe problemen - Je weet niet precies hoe het werk, je leert door het te doen, je hebt een probe nodig –> een klein, veilig te mislukken experiment, a prototype, a MVP. Complexe problemen lijken op complicated problemen achteraf, we hadden beter moeten plannen. Maar je hebt experimentation nodig voor complexe problemen, ga achter de onderzekerheid aan totdat het alleen nog een complicated probleem is ipv complex. Begin bij een complex probleem altijd met de core complexity. Tackle risico en waarde en het begin.
- Chaotic - gelijk acteren, niet afwachten.
Hoe beweeg je van een Big idea naar user stories?
- Start met een goed Big Idea, ga eerst op onderzoek uit.
- Slice the Big idea into MMF, just enough to be worth shipping
- When Big Idea is complex domain, use feature mining to find MMF that will adress core complexitiy, while still being small and providing marketable value
- When Big Idea has moved in to complicated domain, use analysis technique to find and prioritize a list of MMF
- Slice MMF into user stories, use splitting
- Keep the user stories of specific MMF together
What are user stories?
User stories are used to get the customer perspective all the way down into details of the wark, describing every change we intend to make in our product in terms of what this means for the user.
Benefits of user stories
- Team is more motivated as they connected to the purpose of what they are doing.
- They create the right product as they know the main user
