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
[–] 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