Scrum planning en story boards

[semyazaruax]

Beste Tweakers, op mijn werk zijn we sinds kort begonnen met de scrum werkmethode. Dit bevalt zeer goed moet ik zelf zeggen, echter gebeurd het wel regelmatig dat onze programmeurs een situatie onderschatten. Ze denken dan niet verder dan hun neus lang is zeg maar.

Nu dacht ik er zelf aan om (voor grotere onderdelen / sprints) een story board te gaan hanteren. Dus bijvoorbeeld:

1. Wat is het doel
2. Hoe gaan we dit doel behalen
3. Met welke middelen gaan we dit behalen
4. Wie gaat het doen, van wie ben je afhankelijk, welke bestaande onderdelen kunnen beïnvloed worden door jouw aanpassingen, welke (on)mogelijkheden en problemen ga je tegen aan lopen et cetera

Nu zou ik graag jullie mening willen over hoe je een goede planning hoort te doen, en of jullie denken dat een storyboard zou helpen om ons als team beter en diepgaander te laten denken.

Graag zou ik ook, mits bekend bij jullie, wat software suggesties zien voor het maken van zo'n storyboard.

Ik hoor graag van jullie wat jullie visie en ervaring is betreft plannen en wat goed en niet goed werkt in jullie optiek (binnen een Scrum werkwijze).

FYI: Wij maken zelf gebruik van Trello, maar zijn momenteel de overstap naar Clickup aan het maken.


Met vriendelijke groet

[Joostje123]

Jij bent een manager?
Je hoort zeker nooit over de story die te hoog ingeschat zijn? Omdat je daar geen interesse in hebt.

Uiteindelijk levelt het wel uit.
Leer van je inschatting iedere retro even stil bij staan.

En dan worden de zware 5 punters vanzelf 8 of 13. Er naast zitten zal altijd en iedere sprint gebeuren.
Maar uiteindelijk zie je wel hoeveel punten je verbrand in de sprint.

Schat je alles te laag in verbrand je minder punten. Kan je minder oppakken.

Dus oftewel niet te druk om maken!

[semyazaruax]

Hoi Joostje123, dankjewel voor je antwoord nee geen manager maar een developer. En de vraag is puur gesteld om er van te leren hoe het beter kan en de gedachtegang beter te gaan begrijpen. We zijn een beginnend team en willen graag de juiste manieren leren en onszelf oriënteren om een goede werkwijze te vinden dus vandaar mijn vraag hier

[momania]

Hebben jullie allemaal scrum training gehad? En dan bedoel ik ook echt: allemaal.
Want als je al gaat zoeken naar digitale tools voor storyboarding, heb je scrum niet helemaal begrepen denk ik.

Pak een groot whiteboard, of nog beter: schilder een hele muur met whiteboard verf, en doe alles daarop.
Past het er niet meer, op heb je of teveel WIP, te veel in je backlog en heb je dus te veel overhead.

Je kan wel een globale roadmap maken, maar dat is echt niet meer dan een high-level milestone beschrijving.

[418O2]

semyazaruax schreef op maandag 9 april 2018 @ 21:17:
Hoi Joostje123, dankjewel voor je antwoord nee geen manager maar een developer. En de vraag is puur gesteld om er van te leren hoe het beter kan en de gedachtegang beter te gaan begrijpen. We zijn een beginnend team en willen graag de juiste manieren leren en onszelf oriënteren om een goede werkwijze te vinden dus vandaar mijn vraag hier

Ik zou elke user-story net even iets verder uitdiepen. Dan kom je er ook eerder achter of misschien niet alle requirements helder genoeg zijn, of er bijvoorbeeld impact is op andere (al dan niet reeds gebouwde) functionaliteit.

Is het een onervaren team?

[BCC]

Als je plant is het geen scrum 😁 maar ik zou zeker in het begin elke vrijdag voor uitloop leeglaten. Dan kun je namelijk de komende paar weken successen vieren/eerder naar huis. En dat tzt vervangen met een lijstje fun to haves.

[ Voor 4% gewijzigd door BCC op 09-04-2018 21:21 ]

[Xanland]

Bij dit soort zaken kan je jezelf ook wel nog veel meer vragen stellen:

1. Wat is 1 effort, pratend over planningpoker? Het is niet aan te raden om te denken aan een tijdseenheid, maar juist de moeite/complexiteit.
2. Hoe groot mag een Epic/Feature/PBI/Task zijn?
3. Als we dit PBI af hebben, kan ik het opleveren? (Zou je jezelf bij elk PBI moeten vragen.)

Op een gegeven moment weet je ook wat je in een iteratie, als je dus echt scrum praat, kan opleveren als team. Vergeet ook niet zaken als een retro (alleen team, liefst hoe je dit tijden je iteratie bij mbv goreflect oid) en review (team+stakeholders), waar je inderdaad achterkomt dat je iets niet helemaal lekker geschat hebt.

Waarschijnlijk ga ik nu al veel te diep, gezien jullie er - zo te lezen - net een beetje mee beginnen. Wel zijn dit al zaken die ik al vaak tegen ben gekomen.

Edit als reactie op jouw post onder deze:
Dat soort zaken doe je toch tussendoor hopelijk? Analys > Ontwikkel > Test, even heel ruw gezegd en geheid dat dat niet altijd mogelijk is. Liefst vind en fix je zo'n bug halverwege als je dan nog lekker in de materie zit.

Inderdaad over de WIP gesproken zou je niet teel veel PBIs tegelijk "open" moeten/mogen hebben staan.

[ Voor 17% gewijzigd door Xanland op 09-04-2018 21:36 ]

[semyazaruax]

Goede reacties guys het is inderdaad een vrij nieuw team, enkele maandjes samen waarvan in het begin niet eens met scrum dus het is allemaal nog vrij nieuw voor ons. Zijn gewoon de beste manier aan het zoeken nu

Woensdag hebben we als staging dag. Dan is het testen en bug fixen tot en met vrijdag.
Maandag hebben we als release dag, dan gaat het dus echt "live" zeg maar.

Elke dag doen we een stand-up om te bespreken wat we gaan doen die dag en wat we de dag er voor hebben gedaan.

Ten opzichten van hoe het was zonder scrum, is het al grote stappen vooruit gegaan hoor dus ik ben alleen positief haha, maar informeren naar maar opties is nooit verkeerd toch?

[Rmg]

semyazaruax schreef op maandag 9 april 2018 @ 21:08:

Nu dacht ik er zelf aan om (voor grotere onderdelen / sprints) een story board te gaan hanteren. Dus bijvoorbeeld:

Waarom past dit niet in je epics/stories/tasks? 1 en 2 passen in epics en stories 3 en 4 prima in stories en tasks.

Sowieso wat schat je dan, toch geen uren? Als je het bij story points houd maakt het over of onderschatten niet uit omdat je het schatten relatief doet en niet in uren. Op een gegeven moment weet je ongeveer hoeveel een team aan storypoints verzet in een sprint, die velocity zal niet veel stijgen of dalen zolang iedereen maar op de zelfde manier (over/onder) schat.

Het hele idee is juist als developers niet te zijn met "wat krijg ik in 2 weken af" maar hoe complex is een taak. Na een aantal iteraties kan je dan iets zeggen over velocity team x doet y storypoints per week.

[ Voor 12% gewijzigd door Rmg op 09-04-2018 21:40 ]

[DVX73]

De sprint review lijkt mij de uitgelezen plek om dit soort zaken met het team te bespreken en zo te zorgen voor een goede oplossing.

[Hydra]

Het doel is om voorspelbaarder te worden. Je schat dus voor elke nieuwe sprint the stories in (wat moet er gebeuren, door wie, hoe 'groot' is het ongeveer, wat zijn risico's). Dit doe je in de refinement. Na de refinement kun je aan het begin van de sprint plannen; dus welke gerefinede stories gaat je team oppakken. Of wel werk past er in de sprint. Na elke sprint doe je ook een retrospective waarin je terugkijkt op de vorige sprint, wat ging er goed, wat ging er niet goed, en zijn dit zaken die verbeterd kunnen worden. Het is belangrijk om dit hele proces te volgen; zonder bijvoorbeeld de refinement is het niet mogelijk om jezelf bij te sturen.

Ook is het zaak om samen af te spreken hoe jullie refinen (een story is 'ready' na de refinement en wat de eisen zijn leg je vast in je definition of ready). Een story is 'af' als hij volgens jullie definition of done afgewerkt is, dus programmeren, test, user acceptance, whatever.

BCC schreef op maandag 9 april 2018 @ 21:20:
Als je plant is het geen scrum 😁

Wat een onzin.

[ Voor 74% gewijzigd door Hydra op 10-04-2018 09:28 ]

[Hopscotch]

Goed dat jullie er zo mee bezig zijn en dat je het zo wilt omarmen. Wat je aangeeft is dat programmeurs dingen onderschatten, maar eigenlijk ook niet de volledige impact van het werk dat gedaan moet worden onderkennen. Ik denk dat je dan vooral moet gaan werken aan je refinement sessies en kritisch moet kijken naar je definition of ready en ook kritisch kijken of je stories die je wilt pokeren ook echt ready zijn.

[Mercatres]

Onderschatten van story points is op zich raar, als team geef je zelf je eigen waarde aan bepaalde tickets/stories. Als jouw team tickets van 1 SP beschrijft als "Snel de code bekijken of het van toepassing is", en 8 "Een complexe feature inbouwen", maar verder de hogere SPs niet aanraakt, ga je inderdaad een vrij lage sprintscore krijgen, maar dat is alsnog de snelheid van jullie team. Sprintscores vergelijken met andere teams heeft dus niet te veel zin.

Ik lees wel een andere issue, namelijk dat de tickets maar zo-zo worden afgemaakt. Jij verwacht - volgens Scrum terecht - dat elke opgeleverde story klaar is voor release. Dat zijn zaken die je bij een retro perfect aan kan kaarten. Wij hebben dat ook een paar keer ondervonden, met name dat de ingeschatte SPs soms toch een andere individuele waarde kregen. Ook op zich niet fout, maar het is wel belangrijk dat tijdens de planningpoker wel over hetzelfde gesproken kan worden.
Wees tijdens die pokersessies ook niet bang om hoog te gooien, wat vaak een indicatie is van nood aan verdere analyse.

[Tsurany]

Het begint met het opstellen van je user stories. In de titel moet het doel van de user story duidelijk worden en ook gelijk de reden waarom die feature nodig is. Het waarom is het belangrijkste, dat bepaald namelijk grotendeels of de door jullie geleverde oplossing wel of niet voldoet.

"Als medewerker wil ik niet elke keer opnieuw moeten inloggen zodat ik sneller kan werken.".
Het doel is dus duidelijk, voorkomen dat de medewerker opnieuw moet inloggen. Vervolgens ga je de story refinen, je gaat dus gezamenlijk bespreken wat precies het probleem is, hoe je dit probleem wilt oplossen, wat je daar voor nodig hebt en of je afhankelijk bent van externe partijen. Dan heb je dus al je punten al behandeld. Het resultaat daarvan zet je in de beschrijving van de story.

Vervolgens ga je de story pokeren. Dat betekent dat je een score aan die story toe kent op basis van alle punten die uit je refinement komen. Die score is niet gebaseerd op tijd (uren, dagen,...) maar op relatieve zwaarte. Dus hoe zwaar is deze story in vergelijking met de andere stories? Het is handig een aantal reference stories te hebben, bijvoorbeeld een lichte story van 3 punten een zware story van 8 punten. Dan poker je de nieuwe stories ten opzichte van die bestaande stories.

In principe poker je niet hoger dan 8 punten, een hoger cijfer geeft aan dat de story dermate complex is dat je hem moet slicen in kleinere stories. Een story van 20 punten kan dus in principe nooit in je sprint komen, die moet nog verder gesliced worden voor dat dit mogelijk is. Laat staan dat stories van 40 of 100 punten in je sprint komen. Met hoge uitzondering kan een story van 13 punten als slicen niet mogelijk is maar dat brengt wel risico met zich mee natuurlijk.

En heb je al een Definition of Done? In die DoD staat namelijk wanneer een story af is. Dat kan zijn dat de code getest is binnen de testomgeving en er een FAT akkoord is maar het kan ook zijn dat het pas af is als het in productie staat, dat is iets wat je onderling moet afspreken.

Het belangrijkste in Scrum is communicatie. Scrum is een empirisch proces en is gebaseerd op transparantie, inspectie en adaptatie. Lees meer. Heel belangrijk is dus het houden van een retro en bespreken wat er mis ging en hoe dat verbeterd kan worden.

Daarnaast kost het ook tijd voor ontwikkelaars om de omslag te maken, daar hebben oudere ontwikkelaars vaak meer moeite mee dan jonge ontwikkelaars. Neem die tijd ook, maar wijk niet af van het Scrum proces. Ga geen onderdelen overslaan of toevoegen omdat dit makkelijker is.

[ Voor 16% gewijzigd door Tsurany op 10-04-2018 10:52 ]