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