14 ms·

My personal experience with story points is that the number never really mattered, but the process of the team discussing how to rate the complexity of a task w

My personal experience with story points is that the number never really mattered, but the process of the team discussing how to rate the complexity of a task was very useful. 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). Overall I tend to avoid using story points, but on the few teams I worked on who really wanted to use it, I always framed it around building shared understanding rather than a metric that is actually useful for estimating work.

bsder 2y ago
In addition, I like the whole "Full Queues Amplify Variability" chart. It's intuitively obvious, but I never realized it was that bad. I'm going to have to run that down and see if it's actually backed by real data. Too many business books are complete flimflam.
- buescher 2y ago
  Reinertsen's books are very, very good. The most recent and most up-to-date is Principles of Product Development Flow, which that chart came from. The previous one, Managing the Design Factory, is pretty similar and I think it's a better read. Another great takeaway from it is to prioritize things by cost of delay, or even better, what he calls Weighted Shortest Job First, where you divide the cost of delay by the expected length of the task. The only problem is that the same people that want to get oddly formal and inappropriately rigorous with things like story points will want to turn cost-of-delay into an accounting exercise - or object that it's impossible because they don't have the accounting system for it - which misses the point entirely.
  - jrs235 2y ago
    Every CTO needs to read that book.
  - jksmith 2y ago
    Yes, and WSJF gives you two units of data: priority and sequencing - because everybody's pet is priority 1. Much better than MoSCoW.
    - buescher 2y ago
      I hadn't specifically seen MoSCoW before. Some people need to have everything spelled out for them, I guess.
    - brightball 2y ago
      That is very true. I'm going to write something up about WSJF in practice in the future, but it has some real benefits to fixing that issue. Particularly when you get the decision makers in a room and get them all to agree on the estimated value of each item. Not only does it remove the numerous priority #1's, it also gets everybody aligned on what the real priority #1 is and why. I've seen it done where people are surveyed separately and it only works well when the people involved are forced to have a conversation to put real numbers to their assumptions, coming out with agreement. The other side effect is that it solves the squeaky wheel problem.
- vitus 2y ago
  The shape is about right for the variance of the M/M/1 queue (what is an M/M/1/∞ queue??), but it's a little disingenuous since variance is a higher-order moment. Standard deviation is probably more sensible to think about here, since that brings it back down to the same scale as the queue length. > Thus the average number of customers in the system is ρ/(1 − ρ) and the variance of number of customers in the system is ρ/(1 − ρ)². This result holds for any work conserving service regime, such as processor sharing. https://en.wikipedia.org/wiki/M/M/1_queue#Average_number_of_customers_in_the_system https://en.wikipedia.org/wiki/M/M/1_queue#Average_number_of_... In the cited example, going from 75% utilization -> 95% utilization drags your standard deviation from a modest 3.5 items in the queue all the way up to 19.5 items. And, in both cases, that's not far off from your average queue length, either.
  - kqr 2y ago
    > what is an M/M/1/∞ queue?? Infinite queue length. M/M/1/k would be a system where once k items are enqueued, some work shedding policy takes over (either rejecting new work or often preferably dropping at the head of the queue.)
immibis 2y ago
"Plans are useless, but planning is indispensable."
- rustbucket 2y ago
  [dead]
- jksmith 2y ago
  Eisenhower. Here's another from the great philosopher Mike Tyson: "Everybody has a plan until they get punched in the face." Point being, have a continuously ready backlog consumed by short iterations with great telemetry - like SpaceX.
freitzkriesler2 2y ago
Those items after your eg are part of the problem why story points don't work for you. You really do need to control the amount of time your devs get distracted by other things. If they're solely focusing on that one project, you'll be fine. Its why i personally appreciate XP more than plain old scrum.
- icedchai 2y ago
  This, 100%. When engineers have focus, no context switching... things get done. When they're interrupted with useless Zoom meetings every 2 hours, productivity drops off the cliff. If you have 2 meetings 1 hour apart, that 1 hour is basically useless: by the time you're in the zone, you're interrupted again.
  - bryanlarsen 2y ago
    And then when we're given a nice long stretch of interruption-free time, we ruin it by hitting HN.
shrimp_emoji 2y ago
> I personally have never been able to translate story points into a reliable indicator You haven't discovered the secret formula: make your estimate and then mindlessly triple it.
- khalladay 2y ago
  multiplying estimates by PI has proven to be a scarily accurate rule of thumb over the course of my career.
  - deleted 2y ago
    [deleted]
hnthrow289570 2y ago
The points are needed because it's convenient to do reports based off of it. If we used estimation language such as "easy, medium, hard, dummy-thicc" they'd still need to assign points to those labels so they can do math on reports and graphs to watch your performance The biggest sin of course is then trying to predict velocity, but the consequences of that usually just make people doing the reporting look silly for no reason. I think even the slow developers rarely get fired, and you also get nothing for clearing more story points than other developers. No bonuses for higher velocity is the real reason no one takes it seriously.
- cassianoleal 2y ago
  > No bonuses for higher velocity is the real reason no one takes it seriously. Bonuses for higher velocity based on guessed story points would be an even bigger reason for not taking it seriously - or rather to overestimate everything in order to gain the impression of higher velocity and the bonus associated.
  - hnthrow289570 2y ago
    Non-developers might have to learn something about development so they can push back on inflated estimates, which honestly would be helpful to everyone. If I quoted you $1,000 to unclog your kitchen sink trap, you'd call bullshit because you can probably find out how easy it is to do that. Likewise, if I quote you 13 points to add a generic error toast message because a POST went badly, you should call bullshit on that too.
    - geraldwhen 2y ago
      And yet Fred will take 2 weeks to do the work, and the team is dysfunctional so only certain people work in certain areas. Fred sucks. We can say his work is easy, and continually make him feel bad without firing him, or we can pretend it’s two weeks.
      - Nathanba 2y ago
JohnFen 2y ago
This is my experience as well. Story points in and of themselves are worthless, but as an excuse to discuss the project as a team, they can have some value.
- tdb7893 2y ago
  My thing for any agile methodology is the self organizing team aspect really is the most important part, any time-like metric going up the chain is gonna be painful. I liked story points when the team used them to get aligned on the work being done. I did not like story points when middle management had them on a chart they would review.
vannevar 2y ago
>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.
rerdavies 2y ago
Software does not exist in a vacuum. You are probably right in thinking that story points should not matter to you, as a developer; but they do matter to external stakeholders. Forecasting and management of expectations is necessary because software often has external real-world dependencies: available funding for a first release, marketing materials, hardware that can't be released without software, trade shows, developer conferences, yearly retail release parties, OEM partners, cyclic stable releases for enterprise customers who won't push software into production without extensive pre-testing, graphics adapters that can't be released without drivers, rockets that won't launch, cars that won't drive, etc. All of these things require some degree of forecasting and appropriately-evolving management of expectations. Here's where we stand. Here's what we can commit to. Here's what we might deliver, but are willing to defer to a future release. Here are the (low value) items were under consideration that we will definitely defer to a future release, here are the features you will need to drop to get feature b in this release. The purpose of story points is to help provide forecasting and management of expectations (with appropriately limited commitments) to stakeholders, on the understanding that forecasts are approximate. Calibrated burndown of story points is pretty much the only basis on which forecasting and management of expectations can be done in an agile process. The key is to make sure that stakeholders understand the difference between forecasting and commitment, and to make sure your development team is appropriately protected by a healthy development process. Whether the author's claim that you get better forecasts by just counting stories, instead of summing story points... color me skeptical. I do get that it prevents some obvious abuses of process, while enabling other that are just as bad. If somebody is using story points as a developer performance metric (which they shouldn't), there's nothing that prevents them from using completed stories as a developer performance metric (which they shouldn't). The corresponding abuse of process to combat that metric would be to hyper-decompose stories.
- JohnAaronNelson 2y ago
  There was a part of the article that discussed that you create tasks, not stories. You can group the tasks into stories or milestones or iterations or epics. In general, he’s saying you should always keep breaking down a task until it’s a 1, since 1s are easy to estimate. The key part that may be missed is the “mob programming” or “pair programming” aspect where all the engineers on a team sit together and work through a story or milestones or epic to come up with a list one 1 point tasks. Obviously this still can’t be done, so the only effective end solution is maximum pair/mob programming unless all tasks in an iteration are accounted for and broken down into easily understandable and estimable bits of work. There is at least some truth to the notion that if you use mob programming, estimating becomes pointless.
recroad 2y ago
Story points were never meant for forecasting. To do that you can use Monte Carlo analysis https://observablehq.com/@danielfrey/monte-carlo-simulation-for-agile-software-development-and https://observablehq.com/@danielfrey/monte-carlo-simulation-...
- piuantiderp 2y ago
  Please don't
vladgiverts 2y ago
I used story points for years with my teams and they worked "as advertised", which is they helped the teams understand the effort, complexity and risk for each story involved. When there was disagreement, it helped them dig deeper to understand why and usually reveal somebody's incorrect assumptions. It helped make sure teams didn't overcommit to the amount of stories they stuffed into a sprint and avoid either burning out, or worse, normalizing not finishing the sprint causing negative impacts to morale/motivation. (For some reason my teams often thought they could do more than the points implied!) Most importantly, when large projects were proposed or were in progress, we were able to give realistic estimates to the various stakeholders about when to expect the various milestones to arrive, which bought us engineers a ton of credibility, trust, and respect with the rest of the company. And yes, management wanted to see the story points and measure the team against them. I told them to F-off. Nicely. Kinda. It helped that I was either a CTO or a senior enough exec in those cases with 3-8 agile teams. I essentially was the middle management and could put a stop to any destructive practices like evaluating teams against their velocity.
- urban_winter 2y ago
  Absolutely my experience too. Story points have been an effective tool for me with multiple teams in several different companies over the past two decades. They aren't, by themselves, the complete answer to any problem - they need to be applied within the context of a healthy team and engineering culture. And some senior management persistently misunderstand them and want to do insane things like compare velocities between teams. But they are a good and useful tool in the hands of a good team.
  - brightball 2y ago
    Healthy engineering culture is a cure for many, many issues.
- Sammi 2y ago
  So story points work when they are used as an internal tool for a team to understand themselves. And story points don't work when they are a tool used to communicate to the external world outside the team.
shalmanese 2y ago
They're also useful in retro for the simple fact that something was written down. If your story point estimate was way off for a particular task, you can pull up the original conversation, identify what assumptions were violated or what new info was surfaced that wasn't present at the original estimation and whether there's learnings/process changes to be made. Of course, retro is usually the first thing to go in a deluded attempt to increase velocity and story points hang on as this vestigial tail, contributing to more cargo cult software engineering. edit: One scenario that might play out: The team all agreed that tasks A, B & C were worth 3, 5 & 1 points respectively but Steve and Mei thought task D was worth 5 points but Carol thought it should be 13 because it involved integration of an external API where her experience was that other API integrations in the past had exposed hidden complexity. Task D ultimately was not completed because during the process of integration, it was discovered that the API did support a key feature that was needed and instead, an in house alternative needed to be built. It was decided that going forward, the team would instead assign a 1 point task to building a toy app for any new API integrations that would then feed into the process of deciding the story points for features requiring that integration.
burnished 2y ago
Yeah, the discussion can be really illuminating. If the points weren't recorded or mentioned afterwards I think it would be a net positive in some cases.
- brightball 2y ago
  That's one of the main points of the approach mapped out. You still get the discussion value, you just end up documenting things better as a practice and make a more concerted effort to add clarity where needed.
brightball 2y ago
That's a very healthy approach to it and deserves applause. Kudos. The goal of mobbing around task breakdowns is to drive the communication and building that shared understanding. Just with an output of writing most of it down in a way that makes it easy to track progress and approximate the size at the same time.

bsder 2y ago

In addition, I like the whole "Full Queues Amplify Variability" chart. It's intuitively obvious, but I never realized it was that bad. I'm going to have to run that down and see if it's actually backed by real data. Too many business books are complete flimflam.

buescher 2y ago
Reinertsen's books are very, very good. The most recent and most up-to-date is Principles of Product Development Flow, which that chart came from. The previous one, Managing the Design Factory, is pretty similar and I think it's a better read. Another great takeaway from it is to prioritize things by cost of delay, or even better, what he calls Weighted Shortest Job First, where you divide the cost of delay by the expected length of the task. The only problem is that the same people that want to get oddly formal and inappropriately rigorous with things like story points will want to turn cost-of-delay into an accounting exercise - or object that it's impossible because they don't have the accounting system for it - which misses the point entirely.
- jrs235 2y ago
  Every CTO needs to read that book.
- jksmith 2y ago
  Yes, and WSJF gives you two units of data: priority and sequencing - because everybody's pet is priority 1. Much better than MoSCoW.
  - buescher 2y ago
    I hadn't specifically seen MoSCoW before. Some people need to have everything spelled out for them, I guess.
  - brightball 2y ago
    That is very true. I'm going to write something up about WSJF in practice in the future, but it has some real benefits to fixing that issue. Particularly when you get the decision makers in a room and get them all to agree on the estimated value of each item. Not only does it remove the numerous priority #1's, it also gets everybody aligned on what the real priority #1 is and why. I've seen it done where people are surveyed separately and it only works well when the people involved are forced to have a conversation to put real numbers to their assumptions, coming out with agreement. The other side effect is that it solves the squeaky wheel problem.
vitus 2y ago
The shape is about right for the variance of the M/M/1 queue (what is an M/M/1/∞ queue??), but it's a little disingenuous since variance is a higher-order moment. Standard deviation is probably more sensible to think about here, since that brings it back down to the same scale as the queue length. > Thus the average number of customers in the system is ρ/(1 − ρ) and the variance of number of customers in the system is ρ/(1 − ρ)². This result holds for any work conserving service regime, such as processor sharing. https://en.wikipedia.org/wiki/M/M/1_queue#Average_number_of_customers_in_the_system https://en.wikipedia.org/wiki/M/M/1_queue#Average_number_of_... In the cited example, going from 75% utilization -> 95% utilization drags your standard deviation from a modest 3.5 items in the queue all the way up to 19.5 items. And, in both cases, that's not far off from your average queue length, either.
- kqr 2y ago
  > what is an M/M/1/∞ queue?? Infinite queue length. M/M/1/k would be a system where once k items are enqueued, some work shedding policy takes over (either rejecting new work or often preferably dropping at the head of the queue.)

immibis 2y ago

"Plans are useless, but planning is indispensable."

rustbucket 2y ago
[dead]
jksmith 2y ago
Eisenhower. Here's another from the great philosopher Mike Tyson: "Everybody has a plan until they get punched in the face." Point being, have a continuously ready backlog consumed by short iterations with great telemetry - like SpaceX.

freitzkriesler2 2y ago

Those items after your eg are part of the problem why story points don't work for you. You really do need to control the amount of time your devs get distracted by other things. If they're solely focusing on that one project, you'll be fine. Its why i personally appreciate XP more than plain old scrum.

icedchai 2y ago
This, 100%. When engineers have focus, no context switching... things get done. When they're interrupted with useless Zoom meetings every 2 hours, productivity drops off the cliff. If you have 2 meetings 1 hour apart, that 1 hour is basically useless: by the time you're in the zone, you're interrupted again.
- bryanlarsen 2y ago
  And then when we're given a nice long stretch of interruption-free time, we ruin it by hitting HN.

shrimp_emoji 2y ago

> I personally have never been able to translate story points into a reliable indicator You haven't discovered the secret formula: make your estimate and then mindlessly triple it.

khalladay 2y ago
multiplying estimates by PI has proven to be a scarily accurate rule of thumb over the course of my career.
- deleted 2y ago
  [deleted]

hnthrow289570 2y ago

The points are needed because it's convenient to do reports based off of it. If we used estimation language such as "easy, medium, hard, dummy-thicc" they'd still need to assign points to those labels so they can do math on reports and graphs to watch your performance The biggest sin of course is then trying to predict velocity, but the consequences of that usually just make people doing the reporting look silly for no reason. I think even the slow developers rarely get fired, and you also get nothing for clearing more story points than other developers. No bonuses for higher velocity is the real reason no one takes it seriously.

cassianoleal 2y ago
> No bonuses for higher velocity is the real reason no one takes it seriously. Bonuses for higher velocity based on guessed story points would be an even bigger reason for not taking it seriously - or rather to overestimate everything in order to gain the impression of higher velocity and the bonus associated.
- hnthrow289570 2y ago
  Non-developers might have to learn something about development so they can push back on inflated estimates, which honestly would be helpful to everyone. If I quoted you $1,000 to unclog your kitchen sink trap, you'd call bullshit because you can probably find out how easy it is to do that. Likewise, if I quote you 13 points to add a generic error toast message because a POST went badly, you should call bullshit on that too.
  - geraldwhen 2y ago
    And yet Fred will take 2 weeks to do the work, and the team is dysfunctional so only certain people work in certain areas. Fred sucks. We can say his work is easy, and continually make him feel bad without firing him, or we can pretend it’s two weeks.
    - Nathanba 2y ago

JohnFen 2y ago

This is my experience as well. Story points in and of themselves are worthless, but as an excuse to discuss the project as a team, they can have some value.

tdb7893 2y ago
My thing for any agile methodology is the self organizing team aspect really is the most important part, any time-like metric going up the chain is gonna be painful. I liked story points when the team used them to get aligned on the work being done. I did not like story points when middle management had them on a chart they would review.

vannevar 2y ago

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

rerdavies 2y ago

Software does not exist in a vacuum. You are probably right in thinking that story points should not matter to you, as a developer; but they do matter to external stakeholders. Forecasting and management of expectations is necessary because software often has external real-world dependencies: available funding for a first release, marketing materials, hardware that can't be released without software, trade shows, developer conferences, yearly retail release parties, OEM partners, cyclic stable releases for enterprise customers who won't push software into production without extensive pre-testing, graphics adapters that can't be released without drivers, rockets that won't launch, cars that won't drive, etc. All of these things require some degree of forecasting and appropriately-evolving management of expectations. Here's where we stand. Here's what we can commit to. Here's what we might deliver, but are willing to defer to a future release. Here are the (low value) items were under consideration that we will definitely defer to a future release, here are the features you will need to drop to get feature b in this release. The purpose of story points is to help provide forecasting and management of expectations (with appropriately limited commitments) to stakeholders, on the understanding that forecasts are approximate. Calibrated burndown of story points is pretty much the only basis on which forecasting and management of expectations can be done in an agile process. The key is to make sure that stakeholders understand the difference between forecasting and commitment, and to make sure your development team is appropriately protected by a healthy development process. Whether the author's claim that you get better forecasts by just counting stories, instead of summing story points... color me skeptical. I do get that it prevents some obvious abuses of process, while enabling other that are just as bad. If somebody is using story points as a developer performance metric (which they shouldn't), there's nothing that prevents them from using completed stories as a developer performance metric (which they shouldn't). The corresponding abuse of process to combat that metric would be to hyper-decompose stories.

JohnAaronNelson 2y ago
There was a part of the article that discussed that you create tasks, not stories. You can group the tasks into stories or milestones or iterations or epics. In general, he’s saying you should always keep breaking down a task until it’s a 1, since 1s are easy to estimate. The key part that may be missed is the “mob programming” or “pair programming” aspect where all the engineers on a team sit together and work through a story or milestones or epic to come up with a list one 1 point tasks. Obviously this still can’t be done, so the only effective end solution is maximum pair/mob programming unless all tasks in an iteration are accounted for and broken down into easily understandable and estimable bits of work. There is at least some truth to the notion that if you use mob programming, estimating becomes pointless.

recroad 2y ago

Story points were never meant for forecasting. To do that you can use Monte Carlo analysis https://observablehq.com/@danielfrey/monte-carlo-simulation-for-agile-software-development-and https://observablehq.com/@danielfrey/monte-carlo-simulation-...

piuantiderp 2y ago
Please don't

vladgiverts 2y ago

I used story points for years with my teams and they worked "as advertised", which is they helped the teams understand the effort, complexity and risk for each story involved. When there was disagreement, it helped them dig deeper to understand why and usually reveal somebody's incorrect assumptions. It helped make sure teams didn't overcommit to the amount of stories they stuffed into a sprint and avoid either burning out, or worse, normalizing not finishing the sprint causing negative impacts to morale/motivation. (For some reason my teams often thought they could do more than the points implied!) Most importantly, when large projects were proposed or were in progress, we were able to give realistic estimates to the various stakeholders about when to expect the various milestones to arrive, which bought us engineers a ton of credibility, trust, and respect with the rest of the company. And yes, management wanted to see the story points and measure the team against them. I told them to F-off. Nicely. Kinda. It helped that I was either a CTO or a senior enough exec in those cases with 3-8 agile teams. I essentially was the middle management and could put a stop to any destructive practices like evaluating teams against their velocity.

urban_winter 2y ago
Absolutely my experience too. Story points have been an effective tool for me with multiple teams in several different companies over the past two decades. They aren't, by themselves, the complete answer to any problem - they need to be applied within the context of a healthy team and engineering culture. And some senior management persistently misunderstand them and want to do insane things like compare velocities between teams. But they are a good and useful tool in the hands of a good team.
- brightball 2y ago
  Healthy engineering culture is a cure for many, many issues.
Sammi 2y ago
So story points work when they are used as an internal tool for a team to understand themselves. And story points don't work when they are a tool used to communicate to the external world outside the team.

shalmanese 2y ago

They're also useful in retro for the simple fact that something was written down. If your story point estimate was way off for a particular task, you can pull up the original conversation, identify what assumptions were violated or what new info was surfaced that wasn't present at the original estimation and whether there's learnings/process changes to be made. Of course, retro is usually the first thing to go in a deluded attempt to increase velocity and story points hang on as this vestigial tail, contributing to more cargo cult software engineering. edit: One scenario that might play out: The team all agreed that tasks A, B & C were worth 3, 5 & 1 points respectively but Steve and Mei thought task D was worth 5 points but Carol thought it should be 13 because it involved integration of an external API where her experience was that other API integrations in the past had exposed hidden complexity. Task D ultimately was not completed because during the process of integration, it was discovered that the API did support a key feature that was needed and instead, an in house alternative needed to be built. It was decided that going forward, the team would instead assign a 1 point task to building a toy app for any new API integrations that would then feed into the process of deciding the story points for features requiring that integration.

burnished 2y ago

Yeah, the discussion can be really illuminating. If the points weren't recorded or mentioned afterwards I think it would be a net positive in some cases.

brightball 2y ago
That's one of the main points of the approach mapped out. You still get the discussion value, you just end up documenting things better as a practice and make a more concerted effort to add clarity where needed.

brightball 2y ago

That's a very healthy approach to it and deserves applause. Kudos. The goal of mobbing around task breakdowns is to drive the communication and building that shared understanding. Just with an output of writing most of it down in a way that makes it easy to track progress and approximate the size at the same time.