5 ms·

>In terms of having utility of estimating how long something will take, I personally have never been able to translate story points into a reliable indicator fo

>In terms of having utility of estimating how long something will take, I personally have never been able to translate story points into a reliable indicator for that for many reasons (e.g team changing, domain changing, variability in operational load outside of development work). If your measure of the utility of story points is how well they help you estimate time, then you're right, they're useless to you. If you're on a scrum team, they're a useful back-of-the-envelope way to estimate which bits of validated functionality you're going to be able to get into the codebase this sprint. No one outside the scrum team should care about story points, and they certainly shouldn't be used to generate reports. Velocity is for the team's benefit, as a tool to help manage workload and schedule.

happytoexplain 2y ago
>back-of-the-envelope way to estimate which bits of validated functionality you're going to be able to get into the codebase this sprint >help you estimate time How are these different?
- roonyh 2y ago
  Same way that throughput and latency is different. You can use it to predict what the team can deliver in a quarter for example. But difficult to give ETAs to individual stakeholders.
  - Nathanba 2y ago
    if you are at a point where you employ such a factory throughput thinking for information workers then you're misusing information workers in my opinion. Focusing on a throughput metric is just as nonsensical as focusing on how many lines of code somebody creates, in fact, it's really astonishingly similar in how nonsensical it is. Bug reports, issues and features are not just lumps of coal that you need somebody with a pickaxe to beat it with. If you are treating employees like cogs then they will mold themselves to be empty, unthinking cogs. They will not think of outside solutions anymore, they will not care anymore, they will just take the next issue and beat it as ordered. In my opinion it could even be seen as the biggest red flag of a team when they start using story points. It fundamentally means that this team started to measure their work in terms of raw issue throughput instead of real value. It may work for a while. Maybe your managers are just so awesome that all the issues they create are perfect and great for the business and you never have to think for yourself at all. But inevitably there will come a point where the company would be better off if everyone was using their full potential but by that point you are stuck with a bunch of cogs that you have molded into cogs over years.
    - roonyh 2y ago
      ah, we are not using it as a measure of teams performance, like throughput though. Its just used to predict what the team can deliver in a sprint or a quarter etc and make business decisions based on that.
      - skydhash 2y ago
        That is kinda the same thing. With story, it’s either we roughly know how to do it or we need to do some research. In te first case, estimates will be wrong because of edge cases and contextual differences. Businesses decisions should be based on things like feature requests from customers, not the amount of “points“ a team can get done.
        StackRanker3000 2y ago
        It’s extremely useful for a business to have a rough idea of when they’ll be able to deliver something. Budgets, contracts, client relationships, marketing, etc are affected by it. So should Engineering give a best effort to estimate that, or just throw up their hands and say “it’s done when it’s done”?
        n4r9 2y ago
        Counterpoint: it's extremely useful for the Trisolarans to know when their next stable period will be, but that doesn't make it reasonable to demand an estimate and factor it into a contract unless you're really really clear about the uncertainty in the estimate.
        StackRanker3000 2y ago
        Yes, we should all live in reality and use our best judgement. If estimating based on story point velocity is literally useless, then no one should be doing it. However if it does help make planning more accurate, even by a little, then it might be worth the cost of doing so. It’s a conversation to be had between different functions, hopefully based on empirical evidence. I feel like a lot of engineers overlook that there’s more to a viable business than just producing high-quality software. People don’t ask for estimates just to annoy developers.
- tbrownaw 2y ago
  The assumption is that it's already unreasonable to expect developers to estimate how many hours something will take, and then due to meetings and such it's effectively impossible for them to then those already bad numbers into calendar days. So instead, the proper answer is to bypass all that by having developers estimate in made-up units that can be added up and trivially converted into calendar days.
  - dilyevsky 2y ago
    The assumption that anyone can estimate work they have never done with a reasonable degree of accuracy is just plain wrong. That is why management pretends they arent doing that either
- dilyevsky 2y ago
  They aren’t. I’ve seen this argument rehashed a thousand times - “we arent estimating time, just complexity so we can estimate how much we can do in a sprint. which is two weeks. wink wink”
  - Rinzler89 2y ago
    Which is just time and effort estimations with extra steps and cargo culting.
    - Viliam1234 2y ago
      Sadly, if you avoid the extra steps and say "I think this will require 10 working days", some manager will reply "are you absolutely 100% sure that it couldn't be done in 9 working days?". For some reason, calling it "10 story points" does not provoke the same instinctive response.
- tgma 2y ago
  Only one requires an overpaid clown (SCRUM master/Program Manager/etc) to do the unit conversion.
- vannevar 2y ago
  One is a fuzzy and subjective measure of how much software a team can develop in a sprint, the other is a precise measurement in a single dimension. I could sit there and try to calculate how many expertise-adjusted person-hours each team member represents, then estimate our capacity that way, but why fool ourselves with that kind of false precision? Just eyeball it the first sprint and then observe how much we get done. Explicitly tying story points to time just invites abuse of the velocity by managers who don't understand how scrum works.
  - mcluck 2y ago
    I frequently hear about this abuse of estimates and even ran in to it myself when I was a more junior engineer. In my opinion, part of maturing as an engineer is learning to call your shots and properly communicate when you aren't sure how accurate you are. It's one thing to say "I promise this will be done tomorrow". It's another thing to say "we're not positive but within the month seems likely"
- fouc 2y ago
  Given that people are generally bad at giving accurate estimates, the story points is asking the question in a different way, it's asking "what's the likely complexity of implementing this?" rather than "how long would it take to implement this?", because people are likely to be too optimistic on the time estimate, and more likely to be accurate on the complexity estimate. It is a multi-step estimating process to arrive at more accurate estimates: 1. estimate complexity via story points, filter out features that will be implemented according to the "complexity budget" 2. break the features down into sub-tasks 3. estimate the time it takes to do each task
bluefirebrand 2y ago
> No one outside the scrum team should care about story points, and they certainly shouldn't be used to generate reports. Velocity is for the team's benefit, as a tool to help manage workload and schedule These two sentences are somewhat in conflict imo. Workload and schedule is tied into capacity planning and resourcing, which happens at a higher level than the scrum team. The people having those conversations need something to go off of, so it's pretty easy to see why they latch onto story points and velocity.. those are numbers that their teams are already producing! I do agree with you that this is a misuse of velocity and story points, but I don't think it's possible to keep such things from being used (abused?) by upper managers above your team
- skydhash 2y ago
  There are other numbers that kept getting ignored like bugs count, backlog size, time lost to tooling and meetings,… maybe those can help with planning and resourcing too. It’s always measure the team’s productivity, not make the team productive.
- samus 2y ago
  Apart from the impact on team motivation and the incentive to inflate estimates, another problem with that approach is that the story points might not correspond cleanly with how much time was actually spent on the task. Story points are anyways an example of multidimensional data squeezed into one dimensions and in the process losing valuable information. Are there teams out there that correct the story points based on actual amount of work and complexity?
  - vannevar 2y ago
    >Apart from the impact on team motivation and the incentive to inflate estimates... Why would story points affect team motivation, and why would a team have any incentive to inflate estimates? The team isn't judged externally by the story points they burn, they're judged by the software they deliver. The team itself should be the sole consumers of their own story points, so inflating them accomplishes nothing from their perspective. >...story points might not correspond cleanly with how much time was actually spent on the task. If something turns out to be easier than expected, then the team should take that as a lesson for the next time they see something similar. This happens all the time, it's the kind of thing to bring up in the retrospective. I tell my teams that every sprint has two products: the validated software that gets produced, and the team that produced it. The team generally gets better as the project goes on, as they learn more about the project and their own capabilities.

happytoexplain 2y ago

>back-of-the-envelope way to estimate which bits of validated functionality you're going to be able to get into the codebase this sprint >help you estimate time How are these different?

roonyh 2y ago
Same way that throughput and latency is different. You can use it to predict what the team can deliver in a quarter for example. But difficult to give ETAs to individual stakeholders.
- Nathanba 2y ago
  if you are at a point where you employ such a factory throughput thinking for information workers then you're misusing information workers in my opinion. Focusing on a throughput metric is just as nonsensical as focusing on how many lines of code somebody creates, in fact, it's really astonishingly similar in how nonsensical it is. Bug reports, issues and features are not just lumps of coal that you need somebody with a pickaxe to beat it with. If you are treating employees like cogs then they will mold themselves to be empty, unthinking cogs. They will not think of outside solutions anymore, they will not care anymore, they will just take the next issue and beat it as ordered. In my opinion it could even be seen as the biggest red flag of a team when they start using story points. It fundamentally means that this team started to measure their work in terms of raw issue throughput instead of real value. It may work for a while. Maybe your managers are just so awesome that all the issues they create are perfect and great for the business and you never have to think for yourself at all. But inevitably there will come a point where the company would be better off if everyone was using their full potential but by that point you are stuck with a bunch of cogs that you have molded into cogs over years.
  - roonyh 2y ago
    ah, we are not using it as a measure of teams performance, like throughput though. Its just used to predict what the team can deliver in a sprint or a quarter etc and make business decisions based on that.
    - skydhash 2y ago
      That is kinda the same thing. With story, it’s either we roughly know how to do it or we need to do some research. In te first case, estimates will be wrong because of edge cases and contextual differences. Businesses decisions should be based on things like feature requests from customers, not the amount of “points“ a team can get done.
      - StackRanker3000 2y ago
        It’s extremely useful for a business to have a rough idea of when they’ll be able to deliver something. Budgets, contracts, client relationships, marketing, etc are affected by it. So should Engineering give a best effort to estimate that, or just throw up their hands and say “it’s done when it’s done”?
        n4r9 2y ago
        Counterpoint: it's extremely useful for the Trisolarans to know when their next stable period will be, but that doesn't make it reasonable to demand an estimate and factor it into a contract unless you're really really clear about the uncertainty in the estimate.
        StackRanker3000 2y ago
        Yes, we should all live in reality and use our best judgement. If estimating based on story point velocity is literally useless, then no one should be doing it. However if it does help make planning more accurate, even by a little, then it might be worth the cost of doing so. It’s a conversation to be had between different functions, hopefully based on empirical evidence. I feel like a lot of engineers overlook that there’s more to a viable business than just producing high-quality software. People don’t ask for estimates just to annoy developers.
tbrownaw 2y ago
The assumption is that it's already unreasonable to expect developers to estimate how many hours something will take, and then due to meetings and such it's effectively impossible for them to then those already bad numbers into calendar days. So instead, the proper answer is to bypass all that by having developers estimate in made-up units that can be added up and trivially converted into calendar days.
- dilyevsky 2y ago
  The assumption that anyone can estimate work they have never done with a reasonable degree of accuracy is just plain wrong. That is why management pretends they arent doing that either
dilyevsky 2y ago
They aren’t. I’ve seen this argument rehashed a thousand times - “we arent estimating time, just complexity so we can estimate how much we can do in a sprint. which is two weeks. wink wink”
- Rinzler89 2y ago
  Which is just time and effort estimations with extra steps and cargo culting.
  - Viliam1234 2y ago
    Sadly, if you avoid the extra steps and say "I think this will require 10 working days", some manager will reply "are you absolutely 100% sure that it couldn't be done in 9 working days?". For some reason, calling it "10 story points" does not provoke the same instinctive response.
tgma 2y ago
Only one requires an overpaid clown (SCRUM master/Program Manager/etc) to do the unit conversion.
vannevar 2y ago
One is a fuzzy and subjective measure of how much software a team can develop in a sprint, the other is a precise measurement in a single dimension. I could sit there and try to calculate how many expertise-adjusted person-hours each team member represents, then estimate our capacity that way, but why fool ourselves with that kind of false precision? Just eyeball it the first sprint and then observe how much we get done. Explicitly tying story points to time just invites abuse of the velocity by managers who don't understand how scrum works.
- mcluck 2y ago
  I frequently hear about this abuse of estimates and even ran in to it myself when I was a more junior engineer. In my opinion, part of maturing as an engineer is learning to call your shots and properly communicate when you aren't sure how accurate you are. It's one thing to say "I promise this will be done tomorrow". It's another thing to say "we're not positive but within the month seems likely"
fouc 2y ago
Given that people are generally bad at giving accurate estimates, the story points is asking the question in a different way, it's asking "what's the likely complexity of implementing this?" rather than "how long would it take to implement this?", because people are likely to be too optimistic on the time estimate, and more likely to be accurate on the complexity estimate. It is a multi-step estimating process to arrive at more accurate estimates: 1. estimate complexity via story points, filter out features that will be implemented according to the "complexity budget" 2. break the features down into sub-tasks 3. estimate the time it takes to do each task

bluefirebrand 2y ago

> No one outside the scrum team should care about story points, and they certainly shouldn't be used to generate reports. Velocity is for the team's benefit, as a tool to help manage workload and schedule These two sentences are somewhat in conflict imo. Workload and schedule is tied into capacity planning and resourcing, which happens at a higher level than the scrum team. The people having those conversations need something to go off of, so it's pretty easy to see why they latch onto story points and velocity.. those are numbers that their teams are already producing! I do agree with you that this is a misuse of velocity and story points, but I don't think it's possible to keep such things from being used (abused?) by upper managers above your team

skydhash 2y ago
There are other numbers that kept getting ignored like bugs count, backlog size, time lost to tooling and meetings,… maybe those can help with planning and resourcing too. It’s always measure the team’s productivity, not make the team productive.
samus 2y ago
Apart from the impact on team motivation and the incentive to inflate estimates, another problem with that approach is that the story points might not correspond cleanly with how much time was actually spent on the task. Story points are anyways an example of multidimensional data squeezed into one dimensions and in the process losing valuable information. Are there teams out there that correct the story points based on actual amount of work and complexity?
- vannevar 2y ago
  >Apart from the impact on team motivation and the incentive to inflate estimates... Why would story points affect team motivation, and why would a team have any incentive to inflate estimates? The team isn't judged externally by the story points they burn, they're judged by the software they deliver. The team itself should be the sole consumers of their own story points, so inflating them accomplishes nothing from their perspective. >...story points might not correspond cleanly with how much time was actually spent on the task. If something turns out to be easier than expected, then the team should take that as a lesson for the next time they see something similar. This happens all the time, it's the kind of thing to bring up in the retrospective. I tell my teams that every sprint has two products: the validated software that gets produced, and the team that produced it. The team generally gets better as the project goes on, as they learn more about the project and their own capabilities.