4 ms·

> 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 w

> 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."

Jtsummers 8y ago
> These points have nothing to do with actual value produced to the business, or the developer's worth / skill. This is true. Story points don't translate to value. They can't. A nail could be worth 5 cents, or it could be a million dollars. Value is determined by the customer and their need. Story points translate to cost. Customers determine the value. They examine the cost. And they determine whether the value is worth the cost. Is that 5 cent nail worth 5 cents or is it the nail that'll save the project? Story points are about developing an effective and consistent estimation tool (how much will this cost or how much time will this take to produce). If your team is inflating their story points, they're idiots. Assign a number to a story or task. If the team has developed consistent and reliable estimates (this takes time to happen) then this number translates with some reasonable fidelity to cost and time to complete the task. If the numbers are unreliable indicators of cost and time, then the team needs to examine their estimation methods. Perhaps bring in other people with more experience to help them. The team (themselves, no one else) has a history of completing so many story points per cycle (sprint, week, month, whatever). So they know that if the customer has asked for an estimated (their estimate) 50 units of work and they can only complete 20 per month on average, then it'll take 2.5 months on average to complete the work. This lets them, you know, plan. And discuss with their customer the priority and objectives. If the customer is only paying for one month of labor, the customer will have to reexamine their objectives and priorities. The customer never sees the story points. They see the cost and time estimates the story points turn into. The managers never see the story points. They see the cost of the projects and the income from customers. The only people who should see and care about the story points are the developers and the project lead. Maybe a statistician if they can't do the math themselves.
- abernard1 8y ago
  > Story points translate to cost. Customers determine the value. They examine the cost. And they determine whether the value is worth the cost. Is that 5 cent nail worth 5 cents or is it the nail that'll save the project? There is absolutely no evidence that story points actually correspond to cost in a product organization (as opposed to a contracting billable hours situation), because the long-term scope of a project is unknown. When does a project actually "end" with respect to its cost vs value production? Is this accounted for via story points? Are all of those things known when starting the first iterations? I would submit the answers to these are "we have no clue." Something that does however correspond to cost is well, cost. Team's have a known salary burn rate, and this is completely independent of how many imaginary points they make. Any organization whose value output is being measured where two weeks is actually such a large timeframe that it needs to be broken down into more granular estimates is 1) delusional about the predictability of their actual value output and 2) pipe fitters working on easy, well-known features. There are many ways of estimating projects as a whole that are equally as (un-)reliable for estimation and take way less time, and these can be coupled together with financial rationalization from the business. If two week increments can't have significant variance for the business to make a profit, and this business is in the extraordinarily high margin software industry, they're working on the wrong problems.

Jtsummers 8y ago

> These points have nothing to do with actual value produced to the business, or the developer's worth / skill. This is true. Story points don't translate to value. They can't. A nail could be worth 5 cents, or it could be a million dollars. Value is determined by the customer and their need. Story points translate to cost. Customers determine the value. They examine the cost. And they determine whether the value is worth the cost. Is that 5 cent nail worth 5 cents or is it the nail that'll save the project? Story points are about developing an effective and consistent estimation tool (how much will this cost or how much time will this take to produce). If your team is inflating their story points, they're idiots. Assign a number to a story or task. If the team has developed consistent and reliable estimates (this takes time to happen) then this number translates with some reasonable fidelity to cost and time to complete the task. If the numbers are unreliable indicators of cost and time, then the team needs to examine their estimation methods. Perhaps bring in other people with more experience to help them. The team (themselves, no one else) has a history of completing so many story points per cycle (sprint, week, month, whatever). So they know that if the customer has asked for an estimated (their estimate) 50 units of work and they can only complete 20 per month on average, then it'll take 2.5 months on average to complete the work. This lets them, you know, plan. And discuss with their customer the priority and objectives. If the customer is only paying for one month of labor, the customer will have to reexamine their objectives and priorities. The customer never sees the story points. They see the cost and time estimates the story points turn into. The managers never see the story points. They see the cost of the projects and the income from customers. The only people who should see and care about the story points are the developers and the project lead. Maybe a statistician if they can't do the math themselves.

abernard1 8y ago
> Story points translate to cost. Customers determine the value. They examine the cost. And they determine whether the value is worth the cost. Is that 5 cent nail worth 5 cents or is it the nail that'll save the project? There is absolutely no evidence that story points actually correspond to cost in a product organization (as opposed to a contracting billable hours situation), because the long-term scope of a project is unknown. When does a project actually "end" with respect to its cost vs value production? Is this accounted for via story points? Are all of those things known when starting the first iterations? I would submit the answers to these are "we have no clue." Something that does however correspond to cost is well, cost. Team's have a known salary burn rate, and this is completely independent of how many imaginary points they make. Any organization whose value output is being measured where two weeks is actually such a large timeframe that it needs to be broken down into more granular estimates is 1) delusional about the predictability of their actual value output and 2) pipe fitters working on easy, well-known features. There are many ways of estimating projects as a whole that are equally as (un-)reliable for estimation and take way less time, and these can be coupled together with financial rationalization from the business. If two week increments can't have significant variance for the business to make a profit, and this business is in the extraordinarily high margin software industry, they're working on the wrong problems.