3 ms·

If you're asking for estimates from devs at all you're probably pushing waterfall on them. If you want to be waterfall, that's fine. If you're forced into doin

by pydry 3y ago

If you're asking for estimates from devs at all you're probably pushing waterfall on them. If you want to be waterfall, that's fine. If you're forced into doing it by your business context, that's also fine. But, you shouldn't be under any illusions about what you're doing. It's a waterfall behavior that will drive waterfall effects.

maccard 3y ago
That's just not true. It _can_ be waterfall, but story points are everywhere in agile development.
- pydry 3y ago
  Story points are for relative sizing are not estimates. That's why you use story points and not hours or days. They're for re-arranging the priority of stories and deciding which ones to do or not.
  - maccard 3y ago
    > relative sizing are not estimates. Relative sizing is still an estimate. > They're for re-arranging the priority of stories and deciding which ones to do or not. Hard disagree - that's what priority is for. Story points are an _estimate_ for how much we can do in a period.
    - pydry 3y ago
      >Relative sizing is still an estimate. Not one which would attract any pressure.
      - regularfry 3y ago
        If you're doing Scrum, then you might have noticed that the Scrum Guide considers the contents of a sprint to be a "commitment" on the part of the team. That "commitment" is usually built by taking the number of story points delivered last sprint, and bin-packing the same number of story points from the backlog into the next sprint. If you don't think toxic managers and scrum masters are going to use that "commitment" to death-march the team if it looks like the sprint goal is going to be missed then you have a far more optimistic view of humanity than I do.
        pydry 3y ago
        Using scrum to extract commitments on a sprint is also just waterfall by another name.
        maccard 3y ago
        Waterfall is not the same as having a plan and commiting to delivering part of it
        pydry 3y ago
        That's exactly waterfall - make a plan up front, commit to it and focus exclusively on delivery. Scrum does that because it considers waterfall on a 2 week cycle to be training wheels for people who have been doing it on 6 month increments and because it considers that "closer" to agile.
        regularfry 3y ago
        Sometimes Scrum does get called "lots of very short waterfalls". It's not entirely wrong, in the current incarnation. [On edit, I see you've made this point below. Yes.] Note that until relatively recently (2020, I think), the Scrum Guide referred not to "commitments" but to "forecasts". That was a much better framing, and I don't know why they changed it.
        maccard 3y ago
        > If you don't think toxic managers and scrum masters If your managers and PM's are toxic you've already lost and no process is going to fix it. The only move is to change your team in that case. If everywhere you look you only see toxic managers though, maybe you're the problem.
        ResearchCode 3y ago
        The non-technical managers and agile coaches are the problem. That's why the best software projects don't have them. Linux kernel developers don't run story ticket velocity poker sprints.

by pydry 3y ago

maccard 3y ago

That's just not true. It _can_ be waterfall, but story points are everywhere in agile development.

pydry 3y ago
Story points are for relative sizing are not estimates. That's why you use story points and not hours or days. They're for re-arranging the priority of stories and deciding which ones to do or not.
- maccard 3y ago
  > relative sizing are not estimates. Relative sizing is still an estimate. > They're for re-arranging the priority of stories and deciding which ones to do or not. Hard disagree - that's what priority is for. Story points are an _estimate_ for how much we can do in a period.
  - pydry 3y ago
    >Relative sizing is still an estimate. Not one which would attract any pressure.
    - regularfry 3y ago
      If you're doing Scrum, then you might have noticed that the Scrum Guide considers the contents of a sprint to be a "commitment" on the part of the team. That "commitment" is usually built by taking the number of story points delivered last sprint, and bin-packing the same number of story points from the backlog into the next sprint. If you don't think toxic managers and scrum masters are going to use that "commitment" to death-march the team if it looks like the sprint goal is going to be missed then you have a far more optimistic view of humanity than I do.
      - pydry 3y ago
        Using scrum to extract commitments on a sprint is also just waterfall by another name.
        maccard 3y ago
        Waterfall is not the same as having a plan and commiting to delivering part of it
        pydry 3y ago
        That's exactly waterfall - make a plan up front, commit to it and focus exclusively on delivery. Scrum does that because it considers waterfall on a 2 week cycle to be training wheels for people who have been doing it on 6 month increments and because it considers that "closer" to agile.
        regularfry 3y ago
        Sometimes Scrum does get called "lots of very short waterfalls". It's not entirely wrong, in the current incarnation. [On edit, I see you've made this point below. Yes.] Note that until relatively recently (2020, I think), the Scrum Guide referred not to "commitments" but to "forecasts". That was a much better framing, and I don't know why they changed it.
      - maccard 3y ago
        > If you don't think toxic managers and scrum masters If your managers and PM's are toxic you've already lost and no process is going to fix it. The only move is to change your team in that case. If everywhere you look you only see toxic managers though, maybe you're the problem.
        ResearchCode 3y ago
        The non-technical managers and agile coaches are the problem. That's why the best software projects don't have them. Linux kernel developers don't run story ticket velocity poker sprints.