4 ms·

> If you don’t include story points or some equivalent, this might be the most misleading metric you could use. I'm sorry, but if you think "story points" is s

> If you don’t include story points or some equivalent, this might be the most misleading metric you could use. I'm sorry, but if you think "story points" is something useful, your organization is already doomed. Story points is an inflationary currency. When your developers realize that somebody important in the company cares about said currency, they will make sure that their work has more of these "story points" in "sprint planning".

skybrian 8y ago
Okay, how does this doom a project? It's just an arbitrary score to begin with, so what's wrong with inflation?
- abernard1 8y ago
  Because now "real" velocity goes down. There's a negative Pavlovian reaction developers have every sprint when 1) "commitment" was not achieved, or 2) story points decreased. To avoid that pain, developers will pad points. This means that when things go according to plan, large sections of a sprint will have no work or people will try to appear busy. The easiest way to avoid that gamesmanship is to not measure things that don't matter, which is all inputs. What matters is outcomes, which can be in the form of money, usage, satisfaction, etc.
  - skybrian 8y ago
    I've only worked on an XP project once, but if we finished early, we either did some refactoring or pulled down another card and started on the next task. You do need some time now and then for refactoring and that's how we did it. Not everything needs to be formally estimated and scheduled. Story points are supposed be a tool to help management with realistic scheduling, not a way to push developers to work as fast as possible. If there's a lack of trust between engineering and management, it sounds like you have bigger problems.
    - abernard1 8y ago
      > Story points are supposed be a tool to help management with realistic scheduling, not a way to push developers to work as fast as possible. There is no empirical evidence that story points are more effective than other forms of estimation. (There's also no evidence that any form of work estimate is related to business value, which is the original criticism of measuring inputs). Secondly, the perverse incentive around sprint boundaries exists and can create bad management practices. If management is actually looking at those estimates retroactively, it means that the team is being evaluated on the performance of their estimates, not on the timely delivery of value. If management is not looking at them--either in the long term or the short term at a sprint boundary--why bother in the first place? Additionally, if it was routine for a team you were on to finish ahead of schedule, my guess is your teammates and/or manager was padding the estimates. In which case, we're back to what I consider a situation where both the company and employees lose because of disengagement.
Jtsummers 8y ago
Maybe it's just because I'm more confident that I won't get fired, but I've not had any trouble telling the higher ups to stop asking about story points. Story points are a way for your teams to improve themselves. If they don't understand that, then teach them. And never report the points (directly) to anyone above the project lead or perhaps one level above that. Any higher and they are too disconnected from both the team and the work to understand what they're seeing. The only thing that higher ups should care about are trends up and down. Your team, after say 6 months, should be pretty steady in their performance if they're using story points correctly. Downward trends should be identified by them and their project lead early and addressed, and if it's an issue that may impact other teams they should communicate that up and out. Upward trends should be celebrated but also examined to see if some change could be duplicated elsewhere (an improvement to your build configuration resulting in faster feedback, adoption of a new development tool or technique, etc.).
- abernard1 8y ago
  > Story points are a way for your teams to improve themselves. These points have nothing to do with actual value produced to the business, or the developer's worth / skill. It's also very easy for a developer to begin to inflate the estimation of tickets they believe they will work on, creating a false sense of confidence. Alternatively, if people work at a "shop" where tickets are so fungible that people pick up whatever the top ticket on the board is, it tells me that they are working on low-value, repeatable things where expertise is unnecessary. It's also not clear that increasing story points (even if they were somehow related to work / hours perfectly) would be useful. I've seen teams drop down to do minimal "work" for months and produce tremendous value because they were reorienting the product to do things successfully. An organization that looked at that labor input, sans objective outcomes in the product, would be doing themselves a disservice. Story points, tickets closed, lines of code: ultimately all of these are a belief in the labor theory of value. But that's the thing. I don't want labor, I want value, and the tragedy that is input-focused measurement is just due to it's easier to do than measure product outcomes. It's always more convenient to say "We did 24 story points this week" than "Our users hate our software, and here's how we know it."

skybrian 8y ago

Okay, how does this doom a project? It's just an arbitrary score to begin with, so what's wrong with inflation?

abernard1 8y ago
Because now "real" velocity goes down. There's a negative Pavlovian reaction developers have every sprint when 1) "commitment" was not achieved, or 2) story points decreased. To avoid that pain, developers will pad points. This means that when things go according to plan, large sections of a sprint will have no work or people will try to appear busy. The easiest way to avoid that gamesmanship is to not measure things that don't matter, which is all inputs. What matters is outcomes, which can be in the form of money, usage, satisfaction, etc.
- skybrian 8y ago
  I've only worked on an XP project once, but if we finished early, we either did some refactoring or pulled down another card and started on the next task. You do need some time now and then for refactoring and that's how we did it. Not everything needs to be formally estimated and scheduled. Story points are supposed be a tool to help management with realistic scheduling, not a way to push developers to work as fast as possible. If there's a lack of trust between engineering and management, it sounds like you have bigger problems.
  - abernard1 8y ago
    > Story points are supposed be a tool to help management with realistic scheduling, not a way to push developers to work as fast as possible. There is no empirical evidence that story points are more effective than other forms of estimation. (There's also no evidence that any form of work estimate is related to business value, which is the original criticism of measuring inputs). Secondly, the perverse incentive around sprint boundaries exists and can create bad management practices. If management is actually looking at those estimates retroactively, it means that the team is being evaluated on the performance of their estimates, not on the timely delivery of value. If management is not looking at them--either in the long term or the short term at a sprint boundary--why bother in the first place? Additionally, if it was routine for a team you were on to finish ahead of schedule, my guess is your teammates and/or manager was padding the estimates. In which case, we're back to what I consider a situation where both the company and employees lose because of disengagement.

Jtsummers 8y ago

Maybe it's just because I'm more confident that I won't get fired, but I've not had any trouble telling the higher ups to stop asking about story points. Story points are a way for your teams to improve themselves. If they don't understand that, then teach them. And never report the points (directly) to anyone above the project lead or perhaps one level above that. Any higher and they are too disconnected from both the team and the work to understand what they're seeing. The only thing that higher ups should care about are trends up and down. Your team, after say 6 months, should be pretty steady in their performance if they're using story points correctly. Downward trends should be identified by them and their project lead early and addressed, and if it's an issue that may impact other teams they should communicate that up and out. Upward trends should be celebrated but also examined to see if some change could be duplicated elsewhere (an improvement to your build configuration resulting in faster feedback, adoption of a new development tool or technique, etc.).

abernard1 8y ago
> Story points are a way for your teams to improve themselves. These points have nothing to do with actual value produced to the business, or the developer's worth / skill. It's also very easy for a developer to begin to inflate the estimation of tickets they believe they will work on, creating a false sense of confidence. Alternatively, if people work at a "shop" where tickets are so fungible that people pick up whatever the top ticket on the board is, it tells me that they are working on low-value, repeatable things where expertise is unnecessary. It's also not clear that increasing story points (even if they were somehow related to work / hours perfectly) would be useful. I've seen teams drop down to do minimal "work" for months and produce tremendous value because they were reorienting the product to do things successfully. An organization that looked at that labor input, sans objective outcomes in the product, would be doing themselves a disservice. Story points, tickets closed, lines of code: ultimately all of these are a belief in the labor theory of value. But that's the thing. I don't want labor, I want value, and the tragedy that is input-focused measurement is just due to it's easier to do than measure product outcomes. It's always more convenient to say "We did 24 story points this week" than "Our users hate our software, and here's how we know it."