612
Bingo of crappy IT processes (lemmy.ml)
submitted 2 years ago by to c/programmer_humor@programming.dev
80 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] 7 points 2 years ago (7 children)

Storypoints are such an artificial concept it doesn't even make sense. Same thing with estimation though. Most numbers are "I pulled it out me arse" unless the task is a one line change. And even then, shit breaks and it becomes useless, so the one line change is estimated to be a day anyway

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 2 points 2 years ago (5 children)

    The idea with story points is you assign them consistently, so the team's velocity is meaningful.

    One team might deliver 30 points in a sprint while another delivers 25 and they deliver the same amount of work

    Of course management want to be able to use story points for tracking, they want to compare teams using them, so you end up with formulas for how many points to assign

    Of course if they score you on points, they get more points, not more work and story points become useless

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 2 points 2 years ago (2 children)

    The idea with story points is you assign them consistently, so the team's velocity is meaningful.

    Yep. But then we got some data and it turned out that story point estimates reliably create a lower quality velocity then simply counting tickets, ignoring their obvious massive size differences.

    Any time spent estimating story points, creates negative value.

    Sources:

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 3 points 2 years ago (1 child)

    They worked well for us, we were updating a big system or adding functionality to it and a lot of the features were similar enough that we could reliably break the work down to sub-single sprint chunks and assign consistent story points to them

    Though I have only been in one team that lasted more than 3 sprints relatively intact, and it's only that team that got good at story pointing work

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 2 years ago

    They worked well for us

    Yeah. I used story points successfully for years.

    After learning about the above data, I asked my team to trial just counting tickets for velocity, and it also works fine.

    The outcomes weren't noticably different, so now we just don't spend the couple hours each sprint that estimating story sizes was costing us.

    My team was hesitant to give up story point estimation, because they didn't want to give up the communication with leadership about which stories were XXL.

    So we kept using the XXL issue tag, but dropped the rest of the estimation process.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 2 points 2 years ago (1 child)

    One time a VP decided to jump in and be a developer and he just pointed a bunch of cards when the dev that was really going to do the work was off for the day. Obviously the points were way too low, so I just padded out the rest of the cards knowing the 7 points on the cards the VP pointed was going to be the entire two week sprint for the other dev and I'd need to to whatever else was put into the sprint.

    And that's how I found out the Product Manager was putting the points into a spreadsheet to track how many points each individual dev was doing. He was actually upset at me for doing 20 points in the sprint. Sure, I padded them out, but why wasn't he bothered by the cards that had too few points on them? Just upset his spreadsheet was screwed up, but couldn't be angry at the VP that under-pointed a bunch of cards.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 2 years ago

    I try really hard when I'm in a scrum master position (my position is pretty chaotic, 20k person organisation, scaled agile, "we need your x skills this program increment, please would you?") to hide my team's individual performance from management. Mostly because your can't compare a system analysts numbers to a mainframe programmer to a mid-range programmer, but also if someone's not pulling their weight I want to solve the problem within the team where we can approach it as equals before resorting to management "performance review" systems.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 2 years ago

    Somewhat agree, but since Scrum is supposed to be bent to the team's needs, it might differ from team to team, but it's fine as long as those numbers are consistently used in one team.

  • permalink
  • fedilink
  • source
  • parent