Story points voor bugs?

[Gropah]

We hadden hier net in de refinement een discussie over of je punten inschat voor bugs. Wat is jullie mening hier over?

Wat mij betreft zijn story points een indicatie van werk. Bugs oplossen is werk, dus moet het een puntenaantal krijgen. Als het binnen dezelfde sprint is, vind ik er nog iets voor te zeggen dat het niet hoeft. Het werk was immers ingeschat voor deze sprint, er is een fout in gevonden, dus de story was eigenlijk nog niet af. Maar als de user story al lang af is en wellicht zelfs opgeleverd, dan is het extra werk en dus ook extra punten (wat mij betreft).

Een snel rondje via google geeft zeer uiteenlopende gedachtes en discussie. Sommigen zijn erg genuanceerd en vinden het een kwestie van smaak. Sommige zijn het met mij eens, anderen zien story points meer als inschatting voor business added value, en daar schuiven ze een bug niet onder dus zou hij geen punten moeten hebben.

[Goudvis]

Gropah schreef op donderdag 22 september 2022 @ 11:46:
We hadden hier net in de refinement een discussie over of je punten inschat voor bugs. Wat is jullie mening hier over?

Wat mij betreft zijn story points een indicatie van werk. Bugs oplossen is werk, dus moet het een puntenaantal krijgen.

Het dubbele bij mijn vorige werk was de filosofie dat een bug per definitie 1 story point is. Bugs geen enkele SP toekennen is wat mij betreft helemaal niet eerlijk.

En het is verleidelijk om story points te vertalen naar 'hoeveelheid werk', maar zou je het als team niet moeten vertalen naar een indicatie van complexiteit?
Wat voor een junior zomaar een 3 is, kan voor een senior met gemak een 1tje zijn.

[JJ Le Funk]

story points is een fictieve eenheid die helpt om de hoeveelheid werk in te schatten voor een komende sprint om te weten wat een team redelijkerwijs aan kan.
die haalbaarheid is belangrijk zodat er successen geboekt worden (stories komen af).

bugs kunnen uit Productie komen of ontdekt gedurende development. Tijdens ontwikkeling: oplossen binnen sprint. Uit productie: iets van leren (post mortem), direct oplossen afhankelijk van ernst of inschatten voor komende sprint. in beide gevallen moet de pijn wel gevoeld worden: 1. of een story in huidige sprint schuift door omdat de bug prio krijgt en ook punten kost; 2. de velocity gaat omlaag de volgende sprint omdat er punten moeten gaan naar de bug.

Dit is goed want als bugs pijn doen dan ga je ze voorkomen, bijvoorbeeld met testautomatisering die continu feedback geeft na elke code commit.

[goldcard]

My two cents:

Op basis van ervaring en metrieken uit het verleden maak je tijdens een sprintplanning een inschatting van de grootte van de user story. Als de ervaring en metrieken je vertellen dat je relatief veel bugs bouwt en die tijdens de test ook vindt, dan hou je daar direct in je inschatting rekening mee. Je hebt dan te maken met meer testwerk en meer development. Je begroot het oplossen en hertesten van deze bugs dan impliciet.

Wanneer je in je sprint bugs voor hertest uit vorige sprints gaat plannen, dan begroot je deze inspanning voor hertest expliciet.

[s0ulmaster]

Ik ben van mening van niet. Waarom?
Het inschatten van stories doe je om aan te geven hoeveel werk (relatief) een nieuwe functionaliteit kost.
Je kunt dat al dan niet opknippen in kleinere taken.
Het feit dat er een bug doorheen geslopen is, is eingelijk een gevolg dat je niet perfect werk kan afleveren, maar je kunt als team wel een hele berg eraan doen om bugs te mitigeren.
Denk aan unittests, integratietests (CI/CD), handmatige testen enz.

Het feit dat je weinig bugs terug krijgt door degelijk testen zul je uiteindelijk terug zien in de velocity van je team, omdat je meer tijd kunt besteden aan je stories.

Een dergelijke test strategie (en de hoeveelheid werk die dat kost) kun je wat mij betreft wel meerekenen bij het schatten van stories.

Zo heb je als team een incentive om hogere kwaliteit af te leveren i.p.v. je velocity te baseren op stories en bugs. Immers, de bugs die er zijn zijn over het algemeen een gevolg dat je je story niet voldoende heb gevalideerd/afgebakend.

@JJ Le Funk geeft redelijk hetzelfde aan als wat ik ook dacht

[ Voor 3% gewijzigd door s0ulmaster op 22-09-2022 11:57 ]

[goldcard]

s0ulmaster schreef op donderdag 22 september 2022 @ 11:55:
...maar je kunt als team wel een hele berg eraan doen om bugs te mitigeren.
Denk aan unittests, integratietests (CI/CD), handmatige testen enz.

Het feit dat je weinig bugs terug krijgt door degelijk testen zul je uiteindelijk terug zien in de velocity van je team, omdat je meer tijd kunt besteden aan je stories.

...

Immers, de bugs die er zijn zijn over het algemeen een gevolg dat je je story niet voldoende heb gevalideerd/afgebakend.

Voor de goede orde: bugs mitigeer je niet door meer te testen of te valideren. Bug mitigeer je door beter te ontwikkelen. Wat je met testen wél mitigeert is de kans dat bugs in productie terecht komen.

[s0ulmaster]

goldcard schreef op donderdag 22 september 2022 @ 11:59:
[...]


Voor de goede orde: bugs mitigeer je niet door meer te testen of te valideren. Bug mitigeer je door beter te ontwikkelen. Wat je met testen wél mitigeert is de kans dat bugs in productie terecht komen.

sematics. Voor mij is een bug pas een bug als ik na het interne testtraject een release maak voor iemand anders en diegene een fout tegenkomt, die ik zelf niet gespot had.
Of noem je een typo die je pas tegenkomt in een unittest ook een bug?

[luukvr]

Ligt er aan waar je story points voor gebruikt. Normaal gesproken om geen onhaalbare planning te creëren, iemand kan namelijk niet eindeloos bug issues oppakken naast de storypoints van andere taken. Als een of ander toplevel persoon wil zien hoeveel 'business added value' is afgerond dan kan hij deze storypoints er altijd uitfilteren?

[Rmg]

Een bug kan je imo niet schatten, van te voren weet je bijna nooit hoeveel tijd een bug oplossen kost. (Even aannemende dat iets als een typefout in een ui element niet een bug is)

En als je dat wel kan omdat het maar elke 1 punt is en "zo gefixed is".

Dan is er iets goed mis in je development process, want waarom worden deze slordigheidjes dan niet tijdens reviews of testen opgepikt.

Daarnaast wil ik als PO juist zien dat de burn down rate omlaag gaat als mensen aan het bugfixen zijn.

Ik hou er niet van als ik aan mn klant uit moet leggen dat het langer duurt dat het product af is ivm technical debt terwijl de burn down rate gelijk blijft of zelfs stijgt door een serie bugs die tijdens de planning veel tijd leken te gaan kosten maar in de sprint zo afgetikt zijn.

[ Voor 33% gewijzigd door Rmg op 22-09-2022 12:33 ]

[MarcoC]

Er bestaat geen feitelijk correct antwoord. Het enige wat je kunt doen is afspreken met je team hoe je hiermee omgaat op een manier waar iedereen achter staat.

Zelf hanteer ik altijd de regel dat als iets binnen een dagdeel opgelost kan worden het geen onderdeel hoeft te zijn van de sprint planning. Dat bespaart een hoop bureaucratie die je beter kunt besteden aan het daadwerkelijk oplossen van het probleem. Mocht dit niet afdoende zijn, dan moeten de werkzaamheden gepland worden volgens het reguliere proces.

[ Voor 11% gewijzigd door MarcoC op 22-09-2022 12:16 ]

[sky-]

Ligt idd aan je afspraken in je team, in het team waar ik onderdeel van ben kennen we ook geen punten (of zwaarte, whatever je gebruikt) toe aan bugs. Wel schatten we de impact in.

[bonzz.netninja]

Het zou helemaal niet zo'n discussie moeten zijn want punten zijn er alleen voor het team zelf om te weten wat je kan wegdraaien, geen performance indicator of iets waarop je rapporteert. Het is een tooltje van het team om ze daarbij te helpen.

Dat betekent dus wel bugs inschatten want je wilt weten hoeveel *werk* je kan doen in een sprint. Als je werk niet inschat maar wel doet ontneem je het team de kans goed te leren wat je kan wegdraaien (en daaruit volgend ontneem je het team de kans voorspelbaarder te zijn)

[HenkEisDS]

Je zou als de story in dezelfde sprint zit de story niet eens mogen afronden, want voldoet niet aan je Definition of Done (wij leveren geteste en bugvrije software op) en waarschijnlijk dan ook niet aan de Acceptance Criteria.

Als de sprint al is afgerond dan zou ik het als developer in elk geval fijn vinden om hier wel een realistisch aantal punten aan te geven, want die gebruik ik ook om mijn sprint/week te plannen. Maar ik heb geen zicht op wat voor impact dit voor een PO heeft.

Ik zou wel eens met het hele team gaan zitten (of een cursus nemen) zodat iedereen dezelfde definities heeft.

Rmg schreef op donderdag 22 september 2022 @ 12:11:
Een bug kan je imo niet schatten, van te voren weet je bijna nooit hoeveel tijd een bug oplossen kost. (Even aannemende dat iets als een typefout in een ui element niet een bug is)

Interessant, ik denk dat je altijd een inschatting moet kunnen geven. Sure er zijn soms obscure bugs die onevenredig veel tijd kosten, maar ik zou er om eerder genoemde redenen toch altijd wel iets van inschatting aan willen hangen. Anders kan ik ook nooit een realistisch aantal andere stories op mij nemen. En het is helemaal niet erg als je een keer sneller of langzamer klaar bent, daar leer je immers weer beter van inschatten.


Offtopic: Leuk topic dit, hier zou ik meer van willen zien op tweakers! Weer eens wat anders dan yet another persoonlijke ontwikkeling, zonnepanelen, leaseauto topic.

[ Voor 6% gewijzigd door HenkEisDS op 22-09-2022 13:07 ]

[henk1994]

Als je een story afgerond heb in een sprint, en je komt er binnen diezelfde sprint nog achter dat er een bug in zit, die te verwijten is aan de afgeronde story, is mijns inziens geen bug maar erachter komen dat de story nog niet klaar is en kost het je ook geen punten. De beloofde functionaliteit werkt immers nog niet naar behoren.

Als de sprint wel afgesloten is en je komt later achter de bug, dan hebben wij de volgende schaal:
0.5 punt: Oorzaak en oplossing bekend
1 punt: Oorzaak bekend, oplossing onbekend
2 punten: Oorzaak en oplossing onbekend.

Geeft soms wel iets vertekend beeld omdat je soms een 2 punter heb die in een halve dag opgelost is, en soms een halve punt in 3 dagen oplost omdat de oplossing gecompliceerder is dan bedacht. Maar over het algemeen levelt dit zichzelf wel redelijk uit bij ons.

En de reden dat we punten geven is omdat het wel resources kost die je niet kunt besteden aan het realiseren van stories.

Owja en trouwens, altijd een unittest schrijven voor de bug zodat je m niet per ongeluk opnieuw kunt introduceren.

[dehardstyler]

Leuk topic dit, wij hebben ook erg veel discussies over story points. Ik vind het sowieso een kut systeem, maar ik ben geen dev.

Waarom wordt dit niet in uren gedaan? Je werkt 8 uur, wordt betaald aan de hand van uren en mijn klok geeft helaas geen story points aan.

Hoeveel story points doen jullie overigens per dag per persoon? Wat is de richtlijn?

[ZpAz]

HenkEisDS schreef op donderdag 22 september 2022 @ 13:06:
(wij leveren geteste en bugvrije software op)

Een unicum

dehardstyler schreef op donderdag 22 september 2022 @ 13:23:
Hoeveel story points doen jullie overigens per dag per persoon? Wat is de richtlijn?

Niet ieders team story point is even "complex" lijkt mij. Dus mogelijk niet vergelijkbaar.

---

Hier hadden we tot op heden enkel story points voor taken die directe features opleveren voor de gebruiker, dus niet voor bugs en ander onderhoud. Maar we gaan dit waarschijnlijk veranderen. Immers, als je al het werk punten geeft kan je alsnog filteren wat the "user feature story points" zijn, en heb je dus enkel meer informatie tot je beschikking dan voorheen.

[Laurens-R]

dehardstyler schreef op donderdag 22 september 2022 @ 13:23:
Leuk topic dit, wij hebben ook erg veel discussies over story points. Ik vind het sowieso een kut systeem, maar ik ben geen dev.

Waarom wordt dit niet in uren gedaan? Je werkt 8 uur, wordt betaald aan de hand van uren en mijn klok geeft helaas geen story points aan.

Hoeveel story points doen jullie overigens per dag per persoon? Wat is de richtlijn?

Omdat uit ervaring blijkt dat mensen daar bijzonder slecht in zijn.

Complexiteit is makkelijker om in te schatten. Je weet al vrij snel dat iets makkelijk, gemiddeld of moeilijk is. En je weet meestal ook nog wel hoeveel moeilijke dingen je in een sprint succesvol kan oppakken. Maar moeilijke dingen kosten niet altijd evenveel tijd... en als je dan een urenschatting maakt zit je er eigenlijk altijd naast omdat het nooit gaat zoals je denkt.

En daarom is het beter om met relatieve scores te schatten. Het is gemiddeld betrouwbaarder dan urenschattingen.

Het aantal storypoints per dag/per persoon is een metric waar ik absolute jeuk van krijg. Als team haal je een gemiddelde velocity per sprint in storypoints en op basis daarvan ga je sturen/bijschaven. Maar ik ga Pietje niet aanspreken op het feit dat hij vandaag maar 4 ipv 8 story points gehaald heeft. Sowieso worden evt roadblocks wel duidelijk tijdens de daily, reviews en retro's... er zijn genoeg momenten waar je kan 'ingrijpen'.

[ Voor 20% gewijzigd door Laurens-R op 22-09-2022 13:45 ]

[DaFeliX]

Mijn scrummaster vertelde mij onlangs nog: "Een bug is 0 punten, want je ticket was blijkbaar nog niet klaar".

Het voordeel van 0-punten is dat je ze dan ook altijd kwijt kunt in je sprint tijdens de plannig. En als je veel bugs maakt (en oppakt) gaat de velocity naar beneden, waardoor het opleveren van minder bugs ineens ook wel interessant wordt.

[Matis]

Wij "time boxte" (is dat een werkwoord) het onderzoeken van bugs altijd in een sprint. Zeg 4 uur per bug voor onderzoek.

Als duidelijk was wat de bug inhield, gingen we op zoek naar een oplossing met inschatting voor de tijd op te fixen.

We braken dus een bug op in onderzoek (vaak fixed time, tenzij super urgent, dan hing er geen maximum aan) en daarna de inschatting van het werk om te fixen.

[Laurens-R]

DaFeliX schreef op donderdag 22 september 2022 @ 13:33:
Mijn scrummaster vertelde mij onlangs nog: "Een bug is 0 punten, want je ticket was blijkbaar nog niet klaar".

Het voordeel van 0-punten is dat je ze dan ook altijd kwijt kunt in je sprint tijdens de plannig. En als je veel bugs maakt (en oppakt) gaat de velocity naar beneden, waardoor het opleveren van minder bugs ineens ook wel interessant wordt.

Muah... daar ben ik het niet helemaal mee eens. Hij heeft gelijk dat een bug geen bug is zolang de DOD nog niet gehaald is en de PO nog niet akkoord is met het eindresultaat. (een bug tijdens het testen van je userstory houd idd in dat je userstory nog niet af is).

Zodra de userstory gedeployed is op productie en achteraf een eindgebruiker met een bug aan komt zetten, is het wmb te kort door de bocht om dan te zeggen "blijkbaar was je ticket nog niet klaar". Ik zou een bug niet storypointen, maar ik zou zeker iets van een complexiteitsschatting doen en daarvoor ruimte vrij maken in een sprint. Want elk uur dat je aan een bug besteed, kan je niet besteden aan een nieuwe userstory. Als je dan 0 punten gaat toekennen aan een bug ben je gewoon je team aan het overbelasten, want elke bug kan er toch nog wel even bij, want 0 punten.

[ Voor 6% gewijzigd door Laurens-R op 22-09-2022 13:39 ]

[chielsen]

Waarom uberhaupt story points? Meestal omdat je wilt kunnen inschatten hoeveel werk je in een sprint op kan nemen, en als een snelheid bepaald is, ook kan schatten wanneer bepaalde features dan af kunnen zijn.
Nou kan je bugs helemaal buiten beschouwing laten bij je planning (bijv 20% mag vrij worden besteed aan bugfixing), maar je kan ook denken dat je hier ook een prioritering aan wilt hangen en dat een kleine belangrijke bug voorgaat op een complexe, minder belangrijke bug (WSJF).
Als je dat laatste wilt doen, dan zal je toch een bepaalde inschatting moeten maken hoe lastig een bug is om op te lossen -> Story Points. Bijkomend voordeel is dat wanneer een inschatting wordt gemaakt er ook al een refinement / analyse plaatsvindt, waardoor je al een stap dichter bij de oplossing bent.

Als je bugs gewoon labelt of een ander type geeft, dan kan je ook prima metrics maken alsof ze geen waarde zouden hebben etc. Dat vind ik geen reden om niet een inschatting te maken.

[DVX73]

DaFeliX schreef op donderdag 22 september 2022 @ 13:33:
Mijn scrummaster vertelde mij onlangs nog: "Een bug is 0 punten, want je ticket was blijkbaar nog niet klaar".

Het voordeel van 0-punten is dat je ze dan ook altijd kwijt kunt in je sprint tijdens de plannig. En als je veel bugs maakt (en oppakt) gaat de velocity naar beneden, waardoor het opleveren van minder bugs ineens ook wel interessant wordt.

En zo ontstaat technical debt

Heb ooit dit issue in een accountantsrapportage opgenomen omdat dit voor een materiele fout in de jaarrekening had gezorgd, daarna is er vanuit de directie opeens wel interesse om dit op te lossen.

[Low-Tech]

Alles inschatten wat je in kan schatten inclusief bugs imho, desnoods een timebox erop. Het kan als gevolg hebben dat de product owner een ander besluit maakt.

Stel een devver zou 4 dagen bezig zijn met een bug dan zou de product owner ook kunnen zeggen laat maar zitten en de gevolgen van de bug accepteren (misschien is het een edge case en hij/zij weet dat we over X periode weer een aanpassing krijgen ).

Je kan dan in ieder geval een gesprek hebben met de product owner, daar helpt een inschating bij. Naast het feit dat een devver zich achter de oren kan krabben als hij uit de tijd gaat lopen, dan is het een mooi moment om pas op de plaats te maken en een nieuw aanvalsplan te maken.

[luukvr]

DaFeliX schreef op donderdag 22 september 2022 @ 13:33:
Mijn scrummaster vertelde mij onlangs nog: "Een bug is 0 punten, want je ticket was blijkbaar nog niet klaar".

Het voordeel van 0-punten is dat je ze dan ook altijd kwijt kunt in je sprint tijdens de plannig. En als je veel bugs maakt (en oppakt) gaat de velocity naar beneden, waardoor het opleveren van minder bugs ineens ook wel interessant wordt.

Oh, dus die scrummaster wist dat jij de bug veroorzaakt? kan misschien alleen als het ticket nog binnen een sprint valt.

Krijg je trouwens ook niet echt een incentive om bugs van anderen op te lossen, lijkt het of je niks doet.

Als je geen schatting maakt kan je een bug ook eigenlijk nooit escaleren of opdelen. Als je van de voren 1 schat en iemand is er al 3 dagen mee bezig dan moeten er toch wel belletjes gaan rinkelen.

Vind het sowieso apart dat sommige agencies storypoints als dagen zien. Dan wordt het inderdaad meer een management tool dan een productie verhogend instrument.

[Ryur]

luukvr schreef op donderdag 22 september 2022 @ 14:02:
[...]
Vind het sowieso apart dat sommige agencies storypoints als dagen zien. Dan wordt het inderdaad meer een management tool dan een productie verhogend instrument.

Of zelfs nog erger, die gebruiken het veld "storypoints" als ureninschatting ...

[Mortis__Rigor]

Bij ons was het principe: bugs krijgen geen story points maar we werken wel bug first. Dus als je pech hebt, moeten er in de sprint veel bugs opgelost worden en zal bijgevolg de velocitiy zakken. Maar de kwaliteit van het product stijgt wel. En deze stijgt niet alleen om de bugs prio krijgen, ook omdat je als analist/developer/tester elk stuk in de flow beter gaat proberen te doen, want anders komt het toch gewoon als een boemerang terug.
Als je bugs gaat inschatten en inplannen is de kans groot dat sommige bugs (die voor de eindgebruiker misschiel wel heel vervelend zijn) nooit opgelost worden omdat de PO/business nieuwe features veel belangrijker vindt.

[scrappy.doo]

Mortis__Rigor schreef op donderdag 22 september 2022 @ 14:18:
Bij ons was het principe: bugs krijgen geen story points maar we werken wel bug first. Dus als je pech hebt, moeten er in de sprint veel bugs opgelost worden en zal bijgevolg de velocitiy zakken. Maar de kwaliteit van het product stijgt wel. En deze stijgt niet alleen om de bugs prio krijgen, ook omdat je als analist/developer/tester elk stuk in de flow beter gaat proberen te doen, want anders komt het toch gewoon als een boemerang terug.
Als je bugs gaat inschatten en inplannen is de kans groot dat sommige bugs (die voor de eindgebruiker misschiel wel heel vervelend zijn) nooit opgelost worden omdat de PO/business nieuwe features veel belangrijker vindt.

Misschien zijn bepaalde nieuwe features ook wel belangrijker dan sommige niet veel voorkomende bugs. Belangrijk is om een goede afweging te kunnen maken waar je je tijd aan wilt spenderen.

[DaFeliX]

DVX73 schreef op donderdag 22 september 2022 @ 14:01:
[...]


En zo ontstaat technical debt
[...]

Ik begrijp niet helemaal hoe het inschatten op 0-punten zorgt voor technical debt, kun je dat wat toelichten?

luukvr schreef op donderdag 22 september 2022 @ 14:02:
[...]

Oh, dus die scrummaster wist dat jij de bug veroorzaakt? kan misschien alleen als het ticket nog binnen een sprint valt.
[...]

Nee, maar dat maakt volgens mij ook niet uit toch? We zijn als team verantwoordelijk voor de code, dus als team lossen we bugs op.

luukvr schreef op donderdag 22 september 2022 @ 14:02:
[...]

Krijg je trouwens ook niet echt een incentive om bugs van anderen op te lossen, lijkt het of je niks doet.
[...]

Gelukkig neemt de ticket wel ruimte in op je bord, dus het lijkt zeker niet of je niets doet. Maar serieus: wat maakt het uit dat het lijkt of je niks doet? Als het goed is weet je zelf wel beter

Overigens staan de bug-tickets bij ons bovenaan, dus bij elke planning pak je er een paar mee.

luukvr schreef op donderdag 22 september 2022 @ 14:02:
[...]

Als je geen schatting maakt kan je een bug ook eigenlijk nooit escaleren of opdelen. Als je van de voren 1 schat en iemand is er al 3 dagen mee bezig dan moeten er toch wel belletjes gaan rinkelen.

Valide punt dat het escaleren moeilijker wordt. Volgens mij 'moet' je een bug ook gewoon fixen, en als dat ten koste gaat van de velocity is dat vervelend maar volgens mij beter dan wachten tot de volgende sprint om 't werk te doen.

[DVX73]

DaFeliX schreef op donderdag 22 september 2022 @ 14:42:
[...]


Ik begrijp niet helemaal hoe het inschatten op 0-punten zorgt voor technical debt, kun je dat wat toelichten?

[....]
[

Als development teams beoordeeld worden op hun velocity dan is het niet aantrekkelijk om bugs op te lossen, deze zijn immers geen story points waard.

De Bugs die opgelost worden zullen met band-aid fix verholpen worden, ook is er geen aanleiding om tijd te steken in de documentatie van bugs en hun oplossing.

[DaFeliX]

DVX73 schreef op donderdag 22 september 2022 @ 14:48:
[...]


Als development teams beoordeeld worden op hun velocity dan is het niet aantrekkelijk om bugs op te lossen, deze zijn immers geen story points waard.

De Bugs die opgelost worden zullen met band-aid fix verholpen worden, ook is er geen aanleiding om tijd te steken in de documentatie van bugs en hun oplossing.

Ik word niet beoordeeld om mijn velocity, dat is een middel om te zien hoeveel ik per sprint kan doen. Maar ja, als je je bonus afhangt van velocity zou ik ook op alles punten zetten, en bovendien bovengemiddeld hoog gaan schatten

En helemaal mee eens dat een bug *goed* opgelosd moet worden, niet met band-aid; alleen ik zie het verband niet tussen een 0-punter en kwaliteit opleveren.

[DVX73]

DaFeliX schreef op donderdag 22 september 2022 @ 14:52:
[...]

En helemaal mee eens dat een bug *goed* opgelosd moet worden, niet met band-aid; alleen ik zie het verband niet tussen een 0-punter en kwaliteit opleveren.

Dat is er vooral met teams die voornamelijk beoordeeld worden op velocity.

[Zenomyscus]

Gropah schreef op donderdag 22 september 2022 @ 11:46:
We hadden hier net in de refinement een discussie over of je punten inschat voor bugs. Wat is jullie mening hier over?

Wat mij betreft zijn story points een indicatie van werk. Bugs oplossen is werk, dus moet het een puntenaantal krijgen. Als het binnen dezelfde sprint is, vind ik er nog iets voor te zeggen dat het niet hoeft. Het werk was immers ingeschat voor deze sprint, er is een fout in gevonden, dus de story was eigenlijk nog niet af. Maar als de user story al lang af is en wellicht zelfs opgeleverd, dan is het extra werk en dus ook extra punten (wat mij betreft).

Een snel rondje via google geeft zeer uiteenlopende gedachtes en discussie. Sommigen zijn erg genuanceerd en vinden het een kwestie van smaak. Sommige zijn het met mij eens, anderen zien story points meer als inschatting voor business added value, en daar schuiven ze een bug niet onder dus zou hij geen punten moeten hebben.

Oef lastig, het is denk ik maar net wat je fijn vind. Story points zijn in mijn ogen ook een indicatie van werk, dus in die zin zou een bug daar ook bij horen. In de praktijk (en daar zit het verschil) wordt dit nogal eens gebruikt voor zoals jij het noemt business added value. Dat hoeven dus niet dezelfde personen te zijn. Die story points betekenen voor mij als developer iets anders dan voor een projectmanager, althans dat is mijn ervaring. Hoewel die story points een indicatie van werk zijn vind ik het in de praktijk makkelijker om dat voor bugs niet te doen. Het wordt omslachtig, dient in mijn ogen amper een doel en tegen de tijd dat ik weet hoe lang ik over een bug doe dan is het opgelost. Story points zie ik zelf meer als een stukje planning. Het is een inschatting van hoe lang iets (uit ervaring) zou moeten duren of hoe ingewikkeld het is, dat kun je spiegelen aan vergelijkbare projecten etc. Bij bugs kun je dat moeilijker doen vind ik.

Maargoed, dat komt van iemand die zich liever helemaal niet bezig houd met story points en gewoon wil programmeren. Af en toe willen klanten het per se op die manier, maar ik hou er zelf niet van. Teveel overhead en teveel mensen die er conclusies aan verbinden die ze niet zouden moeten maken. Mijn bugs zijn af wanneer ze ingecheckt zijn. Al het andere is geneuzel dat voortkomt uit de drang naar controle.

[Zenomyscus]

DVX73 schreef op donderdag 22 september 2022 @ 14:55:
[...]
Dat is er vooral met teams die voornamelijk beoordeeld worden op velocity.

Stiekem ben ik blij dat ik niet voor een bedrijf werk die op die manier zou beoordelen. Het staat mijn vrijheid ook compleet in de weg. Soms kriebelt het gewoon om zaken te refactoren bijvoorbeeld, die vrijheid heb ik nu. Collega's doen dat ook, waardoor het platform enorm vooruit gaat. Als dergelijke zaken ingepland moeten worden dan gaat dat niet werken helaas. Dan zou ik niet bezig zijn met iets omdat het goed voelt, maar omdat het moet. Niks mis mee, dat is nou eenmaal werk, maar simpelweg werken aan iets omdat je daar behoefte aan hebt is echt fantastisch. Die vrijheid die ik heb in mijn baan zorgt voor enorm veel inspiratie en daarmee ga je dingen proberen. Laat daar nou de beste oplossingen uit komen. Ik ben geen fan van agile werken in elk geval. Voor specifieke projecten werkt het en kan het meerwaarde hebben, maar als ontwikkelaar van een groot platform zou ik er niet aan willen beginnen. Ik mis dan de vrijheid om creatief te zijn.

Goed, dit staat wellicht wat ver af van de originele vraag. Dus ik herhaal mezelf nog maar een keer: story points voor bugs zou ik niet doen, ook al is het werk.

[Tarquin]

Andere invalshoek: Ik hoor vaak de discussie dat het niet zomaar bekend is hoeveel een bug kost om op te lossen.
Om die reden plakken we er één punt op: Dat is dan analyse. Dan is hij ofwel gefixed (veel bugs zijn niet zo groot), of je weet er inmiddels zoveel van dat je een goede inschatting kunt maken.

[mcsluis]

Een Userstory wil je het liefst binnen de sprint afronden (dus werkend opleveren). Tijdens de refinement schat je de werkzaamheden inclusief testen/oplossen bugs in. Als je een bug vind op deze userstory is het onderdel van deze story en hoef je die niet te pokeren. Zou je deze bug wel wilen pokeren kan dat pas bij de volgende refinement en zou je in theorie deze bug pas in de volgende sprint kunnen opnemen. Gevolg is dat je de story niet binnen de sprint afkrijgt. Bugs die je vind op develop of productie neem je op op de backlog, ga je pokeren en plan je in een sprint in.

[watcher46]

In het verlengde van wat @DaFeliX zegt, lossen wij bugs op zodra deze in beeld komen.
het is immers onderdeel van een feature die niet goed werkt en dus zijn waarde niet oplevert.
En omdat wij er voor hebben gekozen om ticket-types te gebruiken in Jira, is per sprint duidelijk hoeveel bugs er zijn geweest en hoeveel story's we hebben afgerond. Zodat we na afloop kunnen kijken wat de verhouding tussen die twee is, zodat je een trend kan gaan zien en zodoende voor toekomstige sprint beter weet wat je kunt doen. (hoeveel story's, je test-procedure verbeteren zodat je minder bugs hebt bijv)

Daarnaast bij ons is het pas een bug als het een niet-werkend onderdeel is die wel zou moeten werken volgens de originele story. Zodra het gaat om iets nieuws of een aanpassing, is het gewoon een improvement van de feature.

Ook denk ik niet dat er nergens een foute/goede implementatie van bugs is. Ik vind het vooral belangrijk dat het moet werken voor het team. Als het team beter functioneert door de bugs te schatten, moet je dat vooral doen.

[goldcard]

watcher46 schreef op vrijdag 23 september 2022 @ 09:28:
Als het team beter functioneert door de bugs te schatten, moet je dat vooral doen.

Bug inschatten voor stories die je in een sprint oppakt is niet te doen. Je zal van te voren bijna nooit kunnen bepalen hoeveel bugs er door de devvers geinjecteerd worden. Als het team al langer met elkaar werkt weet je zou je echter wel een beeld moeten hebben van een gemiddeld aantal bugs per story. Bugfinding plan je met je reguliere testinspanning mee, bugfixing en hertesten is eigenlijk altijd een additionele effort die bijdraagt aan de zwaarte van je story. Bij de sprintplanning dus goed bij stilstaan.

Ik ben het zeer zeker eens met de tweakers die aangeven dat wanneer je bugs uit productie ofwel bug uit voorgaande sprints krijgt om op te lossen, dat die impact hebben op je sprintcapaciteit. Je krijgt namelijk meer dev- en meer testinspanning. Dat zou je altijd mee moeten plannen bij de start van de sprint.

Een productiefix die tijdens de sprint opgelost moet worden zou ik niet plannen/begroten, maar ik zou wel meteen de impact op de wél geplande stories aangeven. Ook hier geldt: je gaat capaciteit inzetten die je niet besteed aan het al geplande werk. Het kan zelden beide (én extra werk, én het geplande werk). Als dat wel past heb je te conservatief gepland.

[watcher46]

goldcard schreef op vrijdag 23 september 2022 @ 09:55:
[...]


Bug inschatten voor stories die je in een sprint oppakt is niet te doen. Je zal van te voren bijna nooit kunnen bepalen hoeveel bugs er door de devvers geinjecteerd worden. Als het team al langer met elkaar werkt weet je zou je echter wel een beeld moeten hebben van een gemiddeld aantal bugs per story. Bugfinding plan je met je reguliere testinspanning mee, bugfixing en hertesten is eigenlijk altijd een additionele effort die bijdraagt aan de zwaarte van je story. Bij de sprintplanning dus goed bij stilstaan.

Ik ben het zeer zeker eens met de tweakers die aangeven dat wanneer je bugs uit productie ofwel bug uit voorgaande sprints krijgt om op te lossen, dat die impact hebben op je sprintcapaciteit. Je krijgt namelijk meer dev- en meer testinspanning. Dat zou je altijd mee moeten plannen bij de start van de sprint.

Een productiefix die tijdens de sprint opgelost moet worden zou ik niet plannen/begroten, maar ik zou wel meteen de impact op de wél geplande stories aangeven. Ook hier geldt: je gaat capaciteit inzetten die je niet besteed aan het al geplande werk. Het kan zelden beide (én extra werk, én het geplande werk). Als dat wel past heb je te conservatief gepland.

Klopt, schatten is naar mijn mening ook niet te doen. Mijn punt is meer dat; als het voor het team goed werkt (de manier die ze hebben gekozen) dan moet je het vooral op die manier doen.
Daarom is er in mijn ogen geen goede of foute manier.

Maar conservatief plannen, denk dat er altijd ruimte moet zijn in een sprint. Je kan namelijk ook onverhoopt op techdebt stuiten. (in ieder geval, daar hebben wij veel mee te maken)
Dan wil je wel de ruimte hebben om dat te kunnen fixen zonder dat je de rest van de sprint niet kunt afronden.
Kortom, je wil een beetje flexibel zijn in je sprint. Je kan natuurlijk altijd nog iets extra's opnemen in de sprint.
Zoals onze scrummaster wel eens zegt; under-promise & over-deliver.

[mcsluis]

Goudvis schreef op donderdag 22 september 2022 @ 11:54:
[...]


Het dubbele bij mijn vorige werk was de filosofie dat een bug per definitie 1 story point is. Bugs geen enkele SP toekennen is wat mij betreft helemaal niet eerlijk.

En het is verleidelijk om story points te vertalen naar 'hoeveelheid werk', maar zou je het als team niet moeten vertalen naar een indicatie van complexiteit?
Wat voor een junior zomaar een 3 is, kan voor een senior met gemak een 1tje zijn.

Een storypoint is een relatief getal:

Moeite
Hoeveel moeite kost het om de user story af te ronden, volgens de definition of done?

Complexiteit
Hoe complex is het om de user story te maken? Is het makkelijk, of juist uitdagend?

Onzekerheid
Hoe groot is de kans dat we verrassingen tegenkomen die we vooraf niet hadden voorspeld?

Het oplossen van een bug op de backend kan complexer zijn dan dan het wijzigen van een tekst in de frontend. Het is dan ook vreemd om een bug per definitie 1 punt te geven.

Je hebt dus een baseline voor je storypoints nodig en kan dan bij iedere story/bug afvragen is dit complexer om op te lossen dan story xxx. je krijgt dan vanzelf een logische verdelingen in complexiteit.

[ Voor 8% gewijzigd door mcsluis op 23-09-2022 14:49 ]

[Johnny]

Je moet doen wat werkt voor jouw team. Sommige mensen zien Scrum als een vaste set regels die je religieus moet volgen en raken dan in de war op het moment dat iets niet gedefineerd is en verzanden dan in eindeloze discussies. Dat is het tegenovergestelde van hoe je effectief werkt.

Hier wijzen we standaard 2 punten toe aan bugs. Dat aantal kan worden aangepast als blijkt dat een ander aantal toepasselijker is. Als er teveel bugs binnenkomen kunnen andere dingen uit de sprint worden gegooid op het moment dat het niet meer realistisch is dat die nog af komen.

Aan het einde van de sprint kijk je even naar de burn down, bespreek je even in de retrospective of er misschien dingen in het proces verbeterd kunnen worden en begin je weer opnieuw. Aantal punten afgerond is een heel insignificante metric.

[Anoniem: 80910]

Ik zou het persoonlijk anders doen. Op school zijn de gemiddeldes een 7, geen 10 dus 30% is bugs. Je moet wel naar een 10 toewerken. Als je op die manier er naar kijkt per onderdeel. Het kan dan ook gewoon zijn dat je voor een specifieke feature uitgaat van een 6, waardoor 40% bugs zijn en je dus uit moet gaan van het volgende: de tijd om het op te leveren is 100% maar je hebt een 6. Om die laatste 40% te halen kost je nog eens 80% in tijd. Dus ga je bijna 2× zoveel tijd kwijt zijn. Maar het kan ook zijn door andere factoren dat eerst het ene wel werkt , je een bug vind, die oplost en er een andere bug ontstaat door je oplossing. Dan ben je 3× zoveel tijd kwijt en als het door een ander wordt opgelost kan de oude bug ook weer ontstaan.

[Cartman!]

DaFeliX schreef op donderdag 22 september 2022 @ 13:33:
Mijn scrummaster vertelde mij onlangs nog: "Een bug is 0 punten, want je ticket was blijkbaar nog niet klaar".

Het voordeel van 0-punten is dat je ze dan ook altijd kwijt kunt in je sprint tijdens de plannig. En als je veel bugs maakt (en oppakt) gaat de velocity naar beneden, waardoor het opleveren van minder bugs ineens ook wel interessant wordt.

Want het maken van bugs is een bewuste keuze?

[goldcard]

Cartman! schreef op maandag 26 september 2022 @ 09:19:
[...]

Want het maken van bugs is een bewuste keuze?

Aan de reactie van @Anoniem: 80910 te zien wel ja. Was ook nieuw voor mij. Als dat namelijk zo is, zou ik bij de oplevering aan test wel graag een lijstje van gemaakte bugs meegeleverd willen krijgen. Scheelt weer zoekwerk

[DaFeliX]

Cartman! schreef op maandag 26 september 2022 @ 09:19:
[...]

Want het maken van bugs is een bewuste keuze?

BIj veel devvers zal dat niet zo zijn, hoewel ik natuurlijk alleen voor mijzelf kan spreken

Wat ik bedoel te zeggen is dat als je een bug wel op punten gaat schatten, dit ten koste gaat van wat je aan andere zaken kunt opleveren. Op deze manier is het maken van een bug een risico voor de business. Als je bugs niet inschat, is het risico voor development.

En voor dat risico "afschuiven" op de business is wat voor te zeggen natuurlijk: "lever maar snel op, eventuele bugs pletten we later wel" werkt heel erg goed voor bedrijven die heel erg hard willen groeien. Ik weet dat dit bij hele grote, snelgroeiende, bedrijven is gebeurd. Die zitten nu nog met bugs in legacy code dat draait op oude infra, maar wel bedrijfskritiek is. Maar daardoor konden ze destijds wel hun concurrenten verslaan

[Cartman!]

DaFeliX schreef op maandag 26 september 2022 @ 13:01:
BIj veel devvers zal dat niet zo zijn, hoewel ik natuurlijk alleen voor mijzelf kan spreken

Wat ik bedoel te zeggen is dat als je een bug wel op punten gaat schatten, dit ten koste gaat van wat je aan andere zaken kunt opleveren. Op deze manier is het maken van een bug een risico voor de business. Als je bugs niet inschat, is het risico voor development.

Ja, precies. Het is toch veel handiger om wel een inschatting te maken van de tijd die een bug kost zodat de business bepalen wat ze willen?

En voor dat risico "afschuiven" op de business is wat voor te zeggen natuurlijk: "lever maar snel op, eventuele bugs pletten we later wel" werkt heel erg goed voor bedrijven die heel erg hard willen groeien. Ik weet dat dit bij hele grote, snelgroeiende, bedrijven is gebeurd. Die zitten nu nog met bugs in legacy code dat draait op oude infra, maar wel bedrijfskritiek is. Maar daardoor konden ze destijds wel hun concurrenten verslaan

Kortom; inzichtelijk maken van hoeveel tijd het kost een bug op te lossen is voor iedereen handig; zowel de devs als de business.