6 ms·

> story points (some vague relationship to days of work) Watching people insist that story points are totally not representative of predicted time spent workin

> story points (some vague relationship to days of work) Watching people insist that story points are totally not representative of predicted time spent working on a thing is the funniest shit. The mental gymnastics are incredible.

lawrence19 4y ago
Story points in my experience almost always devolve into time estimates, but I don't agree they have to be the same thing (which is how I interpret your use of "representative"). They are related variables in the same way that temperature and pressure are related, but that doesn't mean they are identical. In a healthy environment, I think "story points" (horrendous name) should approximate "engineering complexity given the current state, skill set, and knowledge of the development team." Time estimates should then be derived from that number based on historical performance of the team in its current state (if you fuck with the team structure, all bets are off and historical data becomes less useful). Ideally a team should use points to do thoughtful analysis of their backlog and think of ways to manipulate scope, invest in cleaning up technical debt, and learn new skills to cheapen the engineering complexity and in turn deliver faster. In practice, what you described is almost always what happens. Stakeholders keep pressing for time estimates, so shit just keeps getting added to the backlog and engineers estimate "how long?" because they are neither encouraged nor empowered to think of it any other way.
- TulliusCicero 4y ago
  But by "complexity" people pretty much always mean "how long it'll take", so it's still time. If something was complex in an abstract way but quick to implement, it would get a small number of story points, not a large number.
  - lawrence19 4y ago
    I don't disagree with you fundamentally, but maybe one way to reframe this is around the type of conversation we're looking to prompt when we point stories. The conversation you're describing (and to be fair that I mostly have experienced as well) is a one-way, "you owe us this, how long will it take?" conversation. The conversation I'm always hoping to have, and that I've seen happen before, is a bi-directional one in which tradeoffs are discussed, priorities are constantly shifting, thoughtful investments are planned, and engineering concerns are a first-class citizen. All of this can happen if you simply consider your estimates "time" as well, but I find that conceptualizing it as "engineering complexity" helps encourage an engineering mindset among the non-developers on a team.
dimal 4y ago
I’ve never understood story points either. Somehow, the argument goes that if you take a process that involves an high level of uncertainty, and you replace clearly defined units of work (time) with vaguely defined units of work (points), this will magically make estimation and planning _more_ accurate. Maybe, since you’re using Fibonnaci numbers, that makes it scientific?! I’ve never seen it actually work in fifteen years of trying.
- dzikimarian 4y ago
  Senior says task will take one day. Junior says it will take 3 days. What do you put into estimate? Story points are simply a way to say "I think that looks roughly like twice the work of that one we estimated before". Usefulness depends on specific environment and who and for what interprets the output (usually, at some organization level, there's excel/Gantt, that will convert them into an exact date. That will fail spectacularly in 99% of the cases).
  - tbrownaw 4y ago
    > Senior says task will take one day. Junior says it will take 3 days. What do you put into estimate? Well, who's planning to do it?
    - dzikimarian 4y ago
      Depending on the team, number of tasks, size of task etc, answer to this ranges from: guy who does the estimate, to: whoever picks it first.
      - dimal 4y ago
        Which is almost always known at the time of estimation, in my experience. In the cases where it's not, then ok, points could make sense, but only as an interim step towards getting to a real time estimate once you know who is doing it. Having a vague point estimate could then be a useful indicator of "we don't really know yet".
adam_arthur 4y ago
Pointing in general is not very helpful in my experience. The engineering manager should know the product area and code well enough to gauge the LOE for tasks and plan, without the unnecessary step of estimation meetings (which likely aren’t going to produce accurate numbers anyway). Could also be a tech lead that does this, but prefer that they’re one in the same. Of course there are many aspects of “pure scrum” I don’t agree with, such as a single sprint goal shared among the team
trentnix 4y ago
1000x yes. I feel like I’ve had the same conversation about story points since 2006. Use story points. Succeed with story points. But don’t try to convince yourself (or me) they aren’t just an analogue for time.
Scubabear68 4y ago
Agree. Especially because they are used mostly to gauge a team’s velocity.
zactato 4y ago
You’re looking at it all wrong, story points are a defensive tool for you the developer. It gives your team a made up unit that no one else understands. If you told someone on Monday that a ticket takes two days they’ll ask you on Thursday why it’s not done. Instead story points combined with team velocity give your team a sense of how much work you can commit to. Of course we all have in our mind that a 5 point story takes a like 3 days. If some director or product leader comes in and looks at these tickets the won’t see any time estimates on them and thus can’t hold you accountable to them. Sue they can look at your team velocity. But that’s generally a higher level moving average of several sprints. Of course this is all imprecise and often isn’t implemented well. I’ve seen it work very well for some teams, where it gave us a good sense of our accomplishments and led to more ownership. It often doesn’t work and just adds overhead. I’ve ditched it for my current team.
- TulliusCicero 4y ago
  I can see how that could be useful for some teams. I guess the teams I've been on just haven't needed that kind of obfuscation. In any case, I was talking about the many devs who insist it's not time even though it is. Having it be a sort of abstracted or obfuscated time increment is fine imo.

lawrence19 4y ago

Story points in my experience almost always devolve into time estimates, but I don't agree they have to be the same thing (which is how I interpret your use of "representative"). They are related variables in the same way that temperature and pressure are related, but that doesn't mean they are identical. In a healthy environment, I think "story points" (horrendous name) should approximate "engineering complexity given the current state, skill set, and knowledge of the development team." Time estimates should then be derived from that number based on historical performance of the team in its current state (if you fuck with the team structure, all bets are off and historical data becomes less useful). Ideally a team should use points to do thoughtful analysis of their backlog and think of ways to manipulate scope, invest in cleaning up technical debt, and learn new skills to cheapen the engineering complexity and in turn deliver faster. In practice, what you described is almost always what happens. Stakeholders keep pressing for time estimates, so shit just keeps getting added to the backlog and engineers estimate "how long?" because they are neither encouraged nor empowered to think of it any other way.

TulliusCicero 4y ago
But by "complexity" people pretty much always mean "how long it'll take", so it's still time. If something was complex in an abstract way but quick to implement, it would get a small number of story points, not a large number.
- lawrence19 4y ago
  I don't disagree with you fundamentally, but maybe one way to reframe this is around the type of conversation we're looking to prompt when we point stories. The conversation you're describing (and to be fair that I mostly have experienced as well) is a one-way, "you owe us this, how long will it take?" conversation. The conversation I'm always hoping to have, and that I've seen happen before, is a bi-directional one in which tradeoffs are discussed, priorities are constantly shifting, thoughtful investments are planned, and engineering concerns are a first-class citizen. All of this can happen if you simply consider your estimates "time" as well, but I find that conceptualizing it as "engineering complexity" helps encourage an engineering mindset among the non-developers on a team.

dimal 4y ago

I’ve never understood story points either. Somehow, the argument goes that if you take a process that involves an high level of uncertainty, and you replace clearly defined units of work (time) with vaguely defined units of work (points), this will magically make estimation and planning _more_ accurate. Maybe, since you’re using Fibonnaci numbers, that makes it scientific?! I’ve never seen it actually work in fifteen years of trying.

dzikimarian 4y ago
Senior says task will take one day. Junior says it will take 3 days. What do you put into estimate? Story points are simply a way to say "I think that looks roughly like twice the work of that one we estimated before". Usefulness depends on specific environment and who and for what interprets the output (usually, at some organization level, there's excel/Gantt, that will convert them into an exact date. That will fail spectacularly in 99% of the cases).
- tbrownaw 4y ago
  > Senior says task will take one day. Junior says it will take 3 days. What do you put into estimate? Well, who's planning to do it?
  - dzikimarian 4y ago
    Depending on the team, number of tasks, size of task etc, answer to this ranges from: guy who does the estimate, to: whoever picks it first.
    - dimal 4y ago
      Which is almost always known at the time of estimation, in my experience. In the cases where it's not, then ok, points could make sense, but only as an interim step towards getting to a real time estimate once you know who is doing it. Having a vague point estimate could then be a useful indicator of "we don't really know yet".

adam_arthur 4y ago

Pointing in general is not very helpful in my experience. The engineering manager should know the product area and code well enough to gauge the LOE for tasks and plan, without the unnecessary step of estimation meetings (which likely aren’t going to produce accurate numbers anyway). Could also be a tech lead that does this, but prefer that they’re one in the same. Of course there are many aspects of “pure scrum” I don’t agree with, such as a single sprint goal shared among the team

trentnix 4y ago

1000x yes. I feel like I’ve had the same conversation about story points since 2006. Use story points. Succeed with story points. But don’t try to convince yourself (or me) they aren’t just an analogue for time.

Scubabear68 4y ago

Agree. Especially because they are used mostly to gauge a team’s velocity.

zactato 4y ago

You’re looking at it all wrong, story points are a defensive tool for you the developer. It gives your team a made up unit that no one else understands. If you told someone on Monday that a ticket takes two days they’ll ask you on Thursday why it’s not done. Instead story points combined with team velocity give your team a sense of how much work you can commit to. Of course we all have in our mind that a 5 point story takes a like 3 days. If some director or product leader comes in and looks at these tickets the won’t see any time estimates on them and thus can’t hold you accountable to them. Sue they can look at your team velocity. But that’s generally a higher level moving average of several sprints. Of course this is all imprecise and often isn’t implemented well. I’ve seen it work very well for some teams, where it gave us a good sense of our accomplishments and led to more ownership. It often doesn’t work and just adds overhead. I’ve ditched it for my current team.

TulliusCicero 4y ago
I can see how that could be useful for some teams. I guess the teams I've been on just haven't needed that kind of obfuscation. In any case, I was talking about the many devs who insist it's not time even though it is. Having it be a sort of abstracted or obfuscated time increment is fine imo.