Agile/Scrum

[Yogibeer]

Zoals eerder deze week al geplaatst ben ik voor een studie bezig met een opdracht projectmethodieken.

Ik ben bezig met een opgave die gaat over Scrum.

Ik heb er diverse stof op nageslagen, maar ik loop telkens vast bij het onderdeel story points.

Na het lezen van de literatuur is mij duidelijk dat story points er zijn om je eisen/wensen lijst te prioriteren en zo een inschatting te kunnen maken de impact van een bepaalde userstorie.

Echter snap ik dus helemaal niet hoe je die story points verwerkt op je product backlog of in je eisen en wensenlijst.
Ik zie allemaal getallen en tabellen voorbij komen, maar ik heb hier iets teveel dyscalculie voor vrees ik

Is er iemand bereid om mij antwoord te geven op mijn vraag:
Hoe verwerk je nou precies story points?

[Emgeebee]

Je koppelt een getalletje aan een user story. That's all.

Vaak wordt de Fibonacci reeks gebruikt, d.w.z je wijst altijd 1, 2, 3, 5, 8, 13, 21, 34 etc. punten toe. Wij hebben afgesproken dat 21 de max is, daarna knip je user stories op.

Vaak wordt ook het pokeren van stories gebruikt om punten toe te wijzen. Ieder teamlid geeft individueel aan hoeveel story points een bepaalde story is aan complexiteit, en dan pak je vaak het gemiddelde of discussieer je als er te veel afwijkende inschattingen voorbij komen.

[Yogibeer]

Emgeebee schreef op vrijdag 19 november 2021 @ 15:06:
Je koppelt een getalletje aan een user story. That's all.

Vaak wordt de Fibonacci reeks gebruikt, d.w.z je wijst altijd 1, 2, 3, 5, 8, 13, 21, 34 etc. punten toe. Wij hebben afgesproken dat 21 de max is, daarna knip je user stories op.

Vaak wordt ook het pokeren van stories gebruikt om punten toe te wijzen. Ieder teamlid geeft individueel aan hoeveel story points een bepaalde story is aan complexiteit, en dan pak je vaak het gemiddelde of discussieer je als er te veel afwijkende inschattingen voorbij komen.

Oke. Dus ik heb een eisen/wensen lijst waarop alle user story's staan.
Hier voeg ik dus een kolom aan toe waaraan ik per story bekijk wat de impact is?

Per story prioriteit ik ze via de Fibonacci reeks?

[St@m]

Story points zijn punten die je toekent aan een user story, het aantal punten is een schatting van de effort (en dat begrip is vrij interpretabel, maar kan bijvoorbeeld een combinatie zijn van de tijd die het kost, de moeite die het kost, de resources die het kost) die je nodig hebt om de user story af te ronden.

Na verloop van tijd kun je story's steeds beter inschatten.

Voorbeeld: Iets kan best in uitvoering heel klein zijn, maar kan heel veel moeite kosten om het geregeld te krijgen. Bijvoorbeeld budget, afspraken met leveranciers enz.

[ Voor 18% gewijzigd door St@m op 19-11-2021 15:12 ]

[desmond]

Na het lezen van de literatuur is mij duidelijk dat story points er zijn om je eisen/wensen lijst te prioriteren en zo een inschatting te kunnen maken de impact van een bepaalde userstorie.

Dit klopt niet. Het is een inschatting van de complexiteit of hoeveelheid werk die aan een story wordt gehangen. Voor de planning wordt het aantal beschikbare resources in een sprint uitgedrukt in aantal te verhapstukken storypoints. En dan gaat de Product Owner de prio bepalen om stories aan een sprint toe te kennen.

Impact is weer iets anders: wordt gebruikt om risico's uit te drukken. Risico's worden gewaardeerd naar Impact X KansOpVoordoen.

Volgens de theorie mag je voor storypoints niet het aantal uren werk nemen, maar vaak gebeurt dat wel

[The_Ghost16]

Story points is een inschatting van de complexiteit van de user story. Deze schatting wordt gemaakt door het team. Alles user stories zullen dus een bepaalde complexiteit hebben ten opzichte van elkaar.

Het bepalen van de story points gebeurd door middel van zogenaamde pokersessies gedaan door het team. Op basis van deze story points kun je bepalen wat je in een bepaalde sprint kunt gaan doen. Naar mate je meer sprints hebt gehad weet je beter hoeveel story points je kwijt kunt in 1 sprint.

Prioriteit van je user stories (backlog) wordt bepaald door de Product Owner. Die doet in principe helemaal neits met de story points.

[OfNoAvail]

De storypoints zijn volledig subjectief en zijn dus slechts ter indicatie. Pas op wanneer je gaat rekenen met deze subjectieve punten naar bijv. uren want dat kan eigenlijk dus niet.
Wel kun je na verloop van tijd inschatten en vergelijken tussen stories en/of sprints.

[Yogibeer]

Oke dank allemaal.

Dus als ik het nu goed samenvat:

Met Story points geef je simpelweg de geschatte complexiteit aan van een story.
Je hebt bijvoorbeeld 10 story's en die rankschik je op verwachte impact door ze een waarde te geven.

Het geeft een beeld van de impact van de story's, waarbij de product owner uiteindelijk een inschatting kan maken wat er allemaal mee kan in één sprint?

[ Voor 3% gewijzigd door Yogibeer op 19-11-2021 15:15 ]

[Quicksilver]

Yogibeer schreef op vrijdag 19 november 2021 @ 15:14:
Oke dank allemaal.

Dus als ik het nu goed samenvat:

Met Story points geef je simpelweg de complexiteit aan van een story.
Je hebt bijvoorbeeld 10 story's en die rankschik je op prioriteit door ze een waarde te geven.

Het geeft een beeld van de impact van de story's, waarbij de product owner uiteindelijk een inschatting kan maken wat er allemaal mee kan in één sprint?

Nee, die punten hebben niets met de prio te maken. Dat is aan de product owner om die te bepalen. De punten zijn enkel om de complixiteit van een issue aan te geven (hoeveel tijd/resources ben zijn we als developer kwijt om dit issue op te pakken).

[Emgeebee]

Yogibeer schreef op vrijdag 19 november 2021 @ 15:14:
Oke dank allemaal.

Dus als ik het nu goed samenvat:

Met Story points geef je simpelweg de geschatte complexiteit aan van een story.
Je hebt bijvoorbeeld 10 story's en die rankschik je op verwachte impact door ze een waarde te geven.

Het geeft een beeld van de impact van de story's, waarbij de product owner uiteindelijk een inschatting kan maken wat er allemaal mee kan in één sprint?

Nee, je moet story points en prioriteit los van elkaar zien.

Story points = mate van complexiteit van een story.
Prioriteit = simpelweg hoe hoog ze op de backlog staan.

Een story kan 21 punten hebben maar qua prioriteit helemaal onderaan de backlog bungelen.

[Yogibeer]

Ik had mijn tekst net aangepast van prio naar complexiteit. Jullie waren me alweer voor

Maar denk dat het nu wel begint te landen

[St@m]

En stap af van impact. Impact waarop?

[Furion2000]

Yogibeer schreef op vrijdag 19 november 2021 @ 15:08:
[...]


Oke. Dus ik heb een eisen/wensen lijst waarop alle user story's staan.
Hier voeg ik dus een kolom aan toe waaraan ik per story bekijk wat de impact is?

Per story prioriteit ik ze via de Fibonacci reeks?

Prioriteit is de volgorde (bovenaan de meeste belangrijke), dit staat los van de story points
Story points is een schatting van complexiteit

e.g.
US-1 Ik wil een knop op een scherm zien (niet heel moeilijk dus 1 punt)
US-2 Ik wil dat de knop een super moeilijke calculatie aftrapt (8 punten)

In een sprint ga ik nu beide US oppakken en het lukt mij dus om 9 punten te 'verbranden', mijn velocity is 9 punten. Volgende sprint zou ik dus ook mogelijk een US van 5, 3 en 1 punten kunnen doen.

De kunst is dus om 'tijd' weg te laten uit de calculatie omdat het bewezen zou zijn dat mensen niet goed tijd kunnen inschatten. Om het pokeren (inschatten) van US makkelijker te maken kun je als groep een soort van referentie US's maken zodat het pokeren consistent gebeurd (dit is handig voor nieuwe groepsleden).

Wij knippen bijv. al bij 11 punten op in kleinere US's @Emgeebee doet in zijn groep dat met 21 punten.

[JustAnotherDev]

Yogibeer schreef op vrijdag 19 november 2021 @ 15:14:
Oke dank allemaal.

Dus als ik het nu goed samenvat:

Met Story points geef je simpelweg de geschatte complexiteit aan van een story.
Je hebt bijvoorbeeld 10 story's en die rankschik je op verwachte impact door ze een waarde te geven.

Het geeft een beeld van de impact van de story's, waarbij de product owner uiteindelijk een inschatting kan maken wat er allemaal mee kan in één sprint?

Je moet compliciteit niet verwarren met alleen technische complexiteit. Compliciteit is ook niet de exacte beschrijving van hetgeen wat je inschat met storypoints. Een storypoint vertegenwoordigd hoe "zwaar" een story is om op te pakken. Dan kan komen vanwegen bijv:

• er is weinig kennis over de gebruikte technieken (kan je zien als complexiteit)
• het functionele domein is lastig (kan je zien als complexiteit)
• veel technische afhankelijkheden (kan je zien als complexiteit)
• veel functionele afhankelijkheden

Maar onzekerheid is bijvoorbeeld ook iets waar je rekening mee moet houden. Als de kwaliteit (bijv de functionele beschrijving en acceptatiecriteria) van de story niet goed is, kan het zijn dat je veel rework hebt. Dan duurt het langer voordat je de story af hebt.

Uiteindelijk is het een optelsom en daar hang je een cijfer aan vast. Het cijfer is arbitrair echter geeft het de verhouding van "zwaarte" tussen verschillende stories aan.

Uiteidenlijk gebruik je storypoints om je velocity te bepalen, hoeveel story points je per sprint kan oppakken allemaal met als doel voorspelbaarheid. Vaak is dit iets wat je na meerdere sprint finetuned met het team.

Het heeft dus niks met prioritering te maken. Stel je voor:
Je weet na 10 sprints met het team uitgevoerd te hebben dat je 14 punten per sprint gemiddeld oppakt (je velocity is dan 14 punten) en je hebt 6 stories, met punten 1, 13, 2, 5, 8, 1

Het kan heel goed zijn dat je stories met punten 13, 2 en 5 het belangrijkst zijn, deze leveren het meeste waarde op. Dan kan je de keuze maken. Ik doe de stories met 13 en 2 punten maar er is een grote kans dat je dit niet gaat halen op basis van je 10 eerdere sprints. Echter de verwachting is wel (je geeft een commitment) dat je deze functionaliteit wel oplevert. Je kan er ook voor kiezen om de stories met 2 en 5 punten op te pakken waarbij je ruimte hebt voor twee stories met 1 punt. Hiermee lever je 4 stories op met een totaal aantal punten 9 waarbij je daarna ruimte hebt voor extra werk.

Uiteindelijk wil je zo efficient mogelijk werken. Al je 100% van de tijd je sprint haalt betekend dat je te voorzichtig bent met werk oppakken. Als je altijd maar 60% afrond van hetgeen wat je belooft heb je geen grip op de complexiteit en kloppen je schattingen niet. Persoonlijk denk ik dat als over een langere periode constant een reliability van tussen de 90% en 100% hebt, je goed als team performed.

(reliability is hier dan het percentage storypoints waar je commitment op geeft en die je ook daadwerkelijk verbrand aan het eind van de sprint.)

[ Voor 29% gewijzigd door JustAnotherDev op 19-11-2021 16:06 ]

[Yogibeer]

Nou een dikke onvoldoende gekregen voor mijn inzendopgave.

Vanavond met de betreffende feedback maar weer eens terug de boeken in

User stories op een te hoog niveau uitgeschreven om als user story te kunnen dienen en ook de duur en doorlooptijd van mijn sprints lijken niet te kloppen

[ Voor 37% gewijzigd door Yogibeer op 22-11-2021 11:25 ]

[Widow]

Yogibeer schreef op maandag 22 november 2021 @ 11:10:
Nou een dikke onvoldoende gekregen voor mijn inzendopgave.

Vanavond met de betreffende feedback maar weer eens terug de boeken in

User stories op een te hoog niveau uitgeschreven om als user story te kunnen dienen en ook de duur en doorlooptijd van mijn sprints lijken niet te kloppen

Ik weet niet of je je uitwerking/feedback hier wilt delen zodat we mee kunnen kijken?

[retoohs]

Yogibeer schreef op maandag 22 november 2021 @ 11:10:
User stories op een te hoog niveau uitgeschreven om als user story te kunnen dienen en ook de duur en doorlooptijd van mijn sprints lijken niet te kloppen

In de praktijk is dit 9 van de 10 keer ook zo

[Hydra]

Yogibeer schreef op vrijdag 19 november 2021 @ 15:02:
Na het lezen van de literatuur is mij duidelijk dat story points er zijn om je eisen/wensen lijst te prioriteren en zo een inschatting te kunnen maken de impact van een bepaalde userstorie.

Nee, dat heb je echt verkeerd begrepen. Story points zijn een indicatie van complexiteit. Niet van prioriteit. De volgorde in je backlog wordt gebruikt voor prioriteit. Story points zijn een grove inschatting van de hoeveelheid werk.

Edit: Spuit 11.

[Hydra]

Yogibeer schreef op maandag 22 november 2021 @ 11:10:
User stories op een te hoog niveau uitgeschreven om als user story te kunnen dienen en ook de duur en doorlooptijd van mijn sprints lijken niet te kloppen

Als je nu eens vertelt wat je opgeschreven hebt dan kunnen we misschien ook helpen.

User stories moeten 'ready' zijn; oftewel alle details bevatten om ze uit te kunnen werken. Anders mogen ze uberhaupt niet de sprint in. Je bent zelf geen developer denk ik, en het is voor niet-developers ook vaak lastig deze inschatting te maken. Dat is iets waar ik (lead dev) zelf vaak op bijstuur. In de refinement maken we stories 'ready', het is ook zaak dat alle developers daar input geven als ze iets niet duidelijk hebben.

Doorlooptijds van sprints; 2 weken is de meest gangbare. Dus wat is daar precies het issue mee?

[CVTTPD2DQ]

Yogibeer schreef op maandag 22 november 2021 @ 11:10:
Nou een dikke onvoldoende gekregen voor mijn inzendopgave.

Vanavond met de betreffende feedback maar weer eens terug de boeken in

Ik denk dat dat eigenlijk heel verstandig is. In je opleiding willen ze vast de theorie horen, in het bedrijfsleven worden allerlei regels aangepast aan de realiteit. Zo hebben veel bedrijven een routineprocedure om extra werk tijdens de sprint in te plannen, terwijl dat in 'zuiver' Scrum een doodzonde is. Mensen hier kunnen niet raden wat jouw docent verwacht.

Yogibeer schreef op maandag 22 november 2021 @ 11:10:
User stories op een te hoog niveau uitgeschreven om als user story te kunnen dienen en ook de duur en doorlooptijd van mijn sprints lijken niet te kloppen

Ook zoiets wat van een team en de werkzaamheden afhangt. Voor het ene team is "Fix dat ene deadlock issue in de threadpool" genoeg user story, een ander team begint met een volledig uitgetekende UI-mockup, inclusief minutieus vastgestelde pixelafstanden.

[D-dark]

Het meest simpele is uitgaan van Als gebruiker X wil ik dat Y zo werkt of gaat reageren zodat Z beter gaat.
Dat is de user story in zijn meest basale vorm. Moet je meerdere aanpassingen doen dan krijg je meerdere user stories maar in de praktijk als de aanpassingen op dezelfde plek gedaan moeten worden is het vaak 1 story.

Waarin je onderscheid.
- Wie vraagt het aan of is er bij gebaat.
- Is er 1 persoon mee geholpen of een gehele afdeling of proces.
- Wat levert het op.

Daarop bepaalde productowner zijn prioriteit.

Dan het sprint ready maken.
- Is het probleem duidelijk
- Is er een reproductiescenario (Indien nodig)
- Hebben we als team de kennis in huis.
- Weten we waar de aanpassingen gedaan moeten worden

Daar komt een inschatting uit van het aantal punten. Die kunnen behoorlijk afwijken. Voor en bouwer misschien 1 storypoint. paar uur werk maar voor een tester 5. Meerdere dagen. In overeenstemming wordt bepaald wat haalbaar is.

Vervolgens de sprint.
De productowner krijgt van het scrumteam te horen hoeveel punten hij mag besteden in de sprint. Ofwel wat men aangeeft aan te kunnen. Die vult hij op met de items uit zijn backlog welke al sprintready zijn.

In de ideale situatie zijn alle items klaar aan het einde van de sprint en is er tussentijds al de volgende items gerefined om de backlog van sprint ready items op peil te houden.
Maar dat is een situatie die pas ontstaat als een scrumteam al enige tijd draait.

Wat de sprintlengte van 2 weken betreft is dit om ervoor te zorgen dat er snel, controleerbaar en voorspelbaar nieuwe functionaliteit wordt geleverd welke bruikbaar is.

Langere perioden van 3 a 4 weken zijn mogelijk maar hebben wel als nadeel dat je ongemerkt je userstories groter en complexer laat worden omdat je meer tijd hebt.

[Torgo]

Hey @Yogibeer, Misschien dat deze uitleg van Atlassian je op weg helpt. In het artikel geven ze je ook de mogelijkheid om het te proberen, soms helpt het om even ‘hands-on’ in een tool te prutsen om het echt te snappen.

https://www.atlassian.com...ect-management/estimation

Veel success met je studie! Product Management is een mooi vak, ik kan het je aanbevelen 🙂

[Transportman]

D-dark schreef op maandag 22 november 2021 @ 19:46:
Wat de sprintlengte van 2 weken betreft is dit om ervoor te zorgen dat er snel, controleerbaar en voorspelbaar nieuwe functionaliteit wordt geleverd welke bruikbaar is.

Het gaat ook om snel feedback te krijgen op wat geleverd is en te kunnen verwerken, maar ook intern te evalueren wat er de afgelopen sprint goed is gegaan en wat er verbeterd kan worden.

[Yogibeer]

Ik loop nu vast op het volgende:

In de derde vraag heb ik een eisen/wensen lijstje opgesteld. (Die is goedgekeurd).

Nu is de vervolgvraag:
Maak een inschatting van de inspanning in story points per story voor de totale lijst van eisen en wensen en geef een onderbouwing.
Omvang: 200 – 400 woorden (½ – 1 A4).


Oftewel: Ik moet een inschatting maken van de complexiteit per eis/wens.

Echter kan ik per eis/wens die ik heb beschreven wel meerdere user story's bedenken. Hoe kan ik dit nu dan het beste uitwerken?
*Zucht*

[edie]

Nergens staat dat 1 wens/eis maar 1 user story mag hebben Maak zoveel user stories als je nodig denkt te hebben om het te implementeren. Schat dan daarvan de complexiteit in. Als er daarna user stories zijn met een (te) hoge complexiteit, dan die opsplitsen in kleinere user stories en deze opnieuw inschatten.

[Ozzie]

Moet jij die inschatting maken? Of moet je beschrijven hoe dat in zijn werk zou gaan?

Want inschattingen maken doe je in Scrum juist met een team, dus in je eentje inschattingen gaan maken is eigenlijk zinloos. Je maakt samen inschattingen zodat iedereen op de hoogte is van de inhoud van een story en weet hoeveel werk erin gaat zitten. Dan kan je namelijk als ontwikkelteam de commitment afgeven dat je de hoeveelheid werk in een sprint ook af krijgt.

[Furion2000]

Yogibeer schreef op woensdag 24 november 2021 @ 09:38:
Ik loop nu vast op het volgende:

In de derde vraag heb ik een eisen/wensen lijstje opgesteld. (Die is goedgekeurd).

Nu is de vervolgvraag:
Maak een inschatting van de inspanning in story points per story voor de totale lijst van eisen en wensen en geef een onderbouwing.
Omvang: 200 – 400 woorden (½ – 1 A4).


Oftewel: Ik moet een inschatting maken van de complexiteit per eis/wens.

Echter kan ik per eis/wens die ik heb beschreven wel meerdere user story's bedenken. Hoe kan ik dit nu dan het beste uitwerken?
*Zucht*

Zoals ik het lees middels een voorbeeld;

Eis; Ik wil een grote rode knop zien op de bestaande homepage
Punten: 0,5 punt (of 1 of 8 of 10 maakt niet uit in principe)
Onderbouwing: Een button in HTML is 1 regel en de CSS styling is ook niet complex

Eis; Ik wil een blauwe knop op de bestaande contactpage die terug navigeert naar de homepage
Punten; 1 punten (hier is het interessant, want in verhouding tot de vorige US moet je bewijzen dat deze complexer is dan die andere)
Onderbouwing: Een button en CSS styling is niet heel complex alleen er zit routing bij en een click event, wat het iets complexer/minder behapbaar maakt.

Ik denk vooral dus dat het gaat om de onderlinge verschillen logisch indelen qua punten en je kunt het zelfs omdraaien in je antwoord. Eerst de eis en onderbouwing schrijven en dan lekker naar complexiteit punten gaan verdelen

Ik had alleen wel verwacht dat je in je studiemateriaal minstens de uitleg tot deze vraag ergens terug kunt vinden, je moet toch handvaten hebben?

[ Voor 4% gewijzigd door Furion2000 op 24-11-2021 10:47 ]

[Yogibeer]

Vragen, uitwerking, feedback:
https://www.dropbox.com/s...18gjgw3a1otkta5c028vmrjlf

Eisen/wensenlijst:
https://www.dropbox.com/s...k4tlpl5v9wtpufx2tr25dsua1

Ik snap dus vooral niet hoe ik mijn bestaande eisen/wensen lijst nu omzet naar goede user story's om daar vervolgens storypoints aan toe te kennen.

[ Voor 31% gewijzigd door Yogibeer op 24-11-2021 11:01 ]

[eamelink]

Story points zijn (net als 'User Stories') géén onderdeel van Scrum.

[Erwin537]

Yogibeer schreef op woensdag 24 november 2021 @ 11:00:
Vragen, uitwerking, feedback:
https://www.dropbox.com/s...18gjgw3a1otkta5c028vmrjlf

Eisen/wensenlijst:
https://www.dropbox.com/s...k4tlpl5v9wtpufx2tr25dsua1

Ik snap dus vooral niet hoe ik mijn bestaande eisen/wensen lijst nu omzet naar goede user story's om daar vervolgens storypoints aan toe te kennen.

Je linkjes doen het niet lijkt het.

Maar om in te gaan op je vraag: Voor user stories kan je ook een format aanhouden. Stel we maken een applicatie om taken bij te houden; dan kan je bijvoorbeeld een story hebben "Als gebruiker wil ik taken kunnen toevoegen aan de takenlijst" of "Als gebruiker wil ik taken kunnen afvinken"

Afhankelijk van wat je maakt en de userstory kunnen deze heel klein of juist heel groot zijn. Op het punt dat de story té groot word (bijvoorbeeld een groot deel van de sprint in neemt) is het best practice om de story op te splitsen. Uiteindelijk is een user story niets meer dan een beschrijving van een stuk werk wat gedaan moet worden voor jouw product. Een story kan een volledige functionaliteit bieden, een functionaliteit verbeteren, de voorbereidingen voor een nieuwe functionaliteit of zelfs niets nieuws, maar het refactoren van een stuk code.

Het is puur het opsplitsen in werkbare blokken. En dat hoeft niet tot in super klein detail - er hoeven geen technische details in. Het is niet dat je een story aan een leek geeft en dat diegene gewoon het stappenplan volgt.

Hoe veel teams werken:
Je hebt de titel van de story (Als gebruiker wil ik een taak kunnen toevoegen aan een lijst)
Vervolgens ga je met je team discussiëren wat dat inhoud, wat (ruwweg) gedaan moet worden en of er bepaalde afhankelijkheden zijn buiten het team. Dit noteer je in de details van de story
Dan bepaal je met het team de complexiteit (storypoints). Dit getal (of t-shirt size) betekent niets buitenom jouw team. Het is een oordeel over de verwachte complexiteit van een story die enkel geld binnen de context van jouw team. Het is een soort waarde die ontstaat uit een consensus die je bereikt over tijd en word bepaald door ervaring met andere stories. In een vorige sprint heb jij bv. misschien een bepaalde functionaliteit toegevoegd die vergelijkbaar is met iets wat je nu aan het inschatten bent, dan geef je die story hetzelfde aantal punten. Is het juist simpeler? Dan geef je hem minder punten (en natuurlijk de andere kant op; complexer = meer punten)

[Standeman]

eamelink schreef op woensdag 24 november 2021 @ 11:13:
Story points zijn (net als 'User Stories') géén onderdeel van Scrum.

Klopt helemaal. Scrum beschrijft alleen de rollen, ceremonies, omvang van het (dev) team en hoe de iteraties worden doorlopen. User stories en story points zijn zijn slechts manieren om werk in te schatten, wat geen onderdeel van scrum is.

[MaltheseFalcon]

Yogibeer schreef op woensdag 24 november 2021 @ 11:00:
Vragen, uitwerking, feedback:
https://www.dropbox.com/s...18gjgw3a1otkta5c028vmrjlf

Eisen/wensenlijst:
https://www.dropbox.com/s...k4tlpl5v9wtpufx2tr25dsua1

Ik snap dus vooral niet hoe ik mijn bestaande eisen/wensen lijst nu omzet naar goede user story's om daar vervolgens storypoints aan toe te kennen.

Het opstellen van user stories is geen exacte wetenschap.

Het uitgangspunt is dat een user story binnen één sprint kan worden afgerond. Of dit mogelijk is hangt van een aantal zaken af:
- De duur van de sprint (binnen mijn bedrijf werken we met sprints van 2 of 3 weken).
- Wat is af (defintion of done)?. Moet het product bijvoorbeeld ook volledig getest zijn,handleidingen af, of maak je hier aparte stories voor.
- Wat kan het team aan. Hierbij speelt ervaring binnen het team een rol, maar ook de mate waarin leden elkaar kunnen helpen (t-shaped profielen), of er een juiste balans is inde team rollen (verhouding tussen ontwikkelaars en testers bijvoorbeeld)
- Complexiteit van de story. Hierbij komen story points om de hoek. Het doel van story points is echter niet om de complexiteit te meten, maar is hulpmiddel om als team het gesprek te voeren. Wat voor de één complex is, kan voor de ander eenvoudig zijn ("o dat heb ik wel eens eerder gedaan bij..."). Iets wat simpel gemaakt kan worden, kan echter ook zeer lastig te zijn om te testen. Complexiteit kan ook voort komen uit niet functionele eisen... Hoe meet je bijvoorbeeld een SLA responsetijd van 10 ms in 99.98% van alle requests.
- andere zaken, zoals de volwassenheid van je ontwikkelstraat. Automatiseringsgraat van test en deployment.

Story points hebben ook geen absolute waarde. Ze hebben alleen waarde binnen het team. Wat voor de één 40 punten is, is voor de ander misschien 13 punten of 8. Het is handig om als startend team te hebben over referentie user stories. Hierbij worden naar afgeronde user stories gekeken en bepaald welke user stories een typische '1-punter', '2-punter etc is.

[Yogibeer]

Opgave opnieuw ingestuurd:

Namens de examencommissie mogen wij u laten weten dat u bent geslaagd voor het examen. U hebt hiervoor het cijfer 8 behaald.
Graag feliciteren wij u van harte met het behaalde resultaat!
In de bijlage treft u het bijbehorende certificaat aan.

HEEL ERG BEDANKT VOOR DE HULP ALLEMAAL

[vinom]

Gefeliciteerd! Welke titel of certificaat heb je nu exact behaald?

[Yogibeer]

vinom schreef op donderdag 25 november 2021 @ 08:01:
Gefeliciteerd! Welke titel of certificaat heb je nu exact behaald?

Het was een module uit een verkorte informatica opleiding (HBO).

Omdat ik alle andere modules al heb afgerond ben ik hiermee klaar met de opleiding.

Begrijp overigens niet waarom ik zo'n moeite had dat hele Agile gebeuren te snappen.
In ieder geval dan het toekennen van die story points,etc.

De rest van de opleiding ben ik eigenlijk vrij makkelijk doorheen gefietst

[mwa]

Belangrijk is ook om "HL3 Confirmed" te roepen als het gehele team 3 punten toekent aan een story. Of enkel wij doen dat, geen idee

[Ardana]

Huiswerkvragen mag je bij school neerleggen, daarnaast heeft dit niks te maken met persoonlijke financiën, je studie an sich, of je loopbaan. PFSL is niet bedoeld voor inhoudelijke studievragen. Deze gaat dus op slot.