Ask HN: Devs, is your team using story points to estimate work? Why/Why not?
18 comments
The only time I have seen story points effective is when a team does the same type of work over and over.
For every other team I have seen it is a waste of time, you either under estimate how many points something is and you get moaned at you are late or you over estimate and you are praised for delivering early.
I pretty much caveat every single estimate I give (either time or the made up points) and say "if you want accurate estimates, a good rule of thumb is that I spend 1/4 of the time estimating to planned work - so if I think it will take 4 weeks, I should spend 1 week estimating" - no one ever wants you to do the accurate estimate so when I am moaned at because the estimates are incorrect I refer back to this statement.
What is the actual goal? Is it to track a teams progress (track by actual delivered work), is it to know how long something will take (story points are a distraction), is it to see how much work a team can do in a sprint (remove the 1 day planning/retro and you get an extra day to deliver the work), is it to fit into a bigger team of dependencies (story points, again, are a distraction).
If you are using story points to avoid figuring out how long something will take, then be brave and figure out how long it will take.
(sorry turned a bit ranty!)
For every other team I have seen it is a waste of time, you either under estimate how many points something is and you get moaned at you are late or you over estimate and you are praised for delivering early.
I pretty much caveat every single estimate I give (either time or the made up points) and say "if you want accurate estimates, a good rule of thumb is that I spend 1/4 of the time estimating to planned work - so if I think it will take 4 weeks, I should spend 1 week estimating" - no one ever wants you to do the accurate estimate so when I am moaned at because the estimates are incorrect I refer back to this statement.
What is the actual goal? Is it to track a teams progress (track by actual delivered work), is it to know how long something will take (story points are a distraction), is it to see how much work a team can do in a sprint (remove the 1 day planning/retro and you get an extra day to deliver the work), is it to fit into a bigger team of dependencies (story points, again, are a distraction).
If you are using story points to avoid figuring out how long something will take, then be brave and figure out how long it will take.
(sorry turned a bit ranty!)
Great rant. I especially like the idea of making it clear that estimates cost time to be any good.
I've only ever liked pointing when it was the best way to help people see large differences in opinion on how hard something is within the team AND from the person making the request (although they are asked in such a way that they don't know they are basically pointing).
When people realize there are frequent, large disparities in expectations it helps hammer home the fact that something is structurally wrong that needs to be addressed. Tech debt? Over-zealous or underwhelming attention to testing? Everyone is unique, but this may help drive discussions that go deeper than being asked "why does everything always take at least twice as long as people think it should?"
I've only ever liked pointing when it was the best way to help people see large differences in opinion on how hard something is within the team AND from the person making the request (although they are asked in such a way that they don't know they are basically pointing).
When people realize there are frequent, large disparities in expectations it helps hammer home the fact that something is structurally wrong that needs to be addressed. Tech debt? Over-zealous or underwhelming attention to testing? Everyone is unique, but this may help drive discussions that go deeper than being asked "why does everything always take at least twice as long as people think it should?"
Nope, waste of time.
In the true spirit of Lean, eliminate waste - the wasteful time of estimating things and the overhead of that. When using kanban flow instead of sprints it really doesn't matter what any estimate is.
This smells like someone above is asking when they can have something done so people in the middle have to come up with something.
Maybe the team lead/mgr can test doing the estimating themselves and letting the team just do the work. If you've committed to a feature or fixing a bug and it takes longer or shorter does it matter?
In the true spirit of Lean, eliminate waste - the wasteful time of estimating things and the overhead of that. When using kanban flow instead of sprints it really doesn't matter what any estimate is.
This smells like someone above is asking when they can have something done so people in the middle have to come up with something.
Maybe the team lead/mgr can test doing the estimating themselves and letting the team just do the work. If you've committed to a feature or fixing a bug and it takes longer or shorter does it matter?
> If you've committed to a feature or fixing a bug and it takes longer or shorter does it matter?
It's not, but it's still nice to get a rough estimate, isn't it? It's also useful when you need to prioritize things, because you often cannot fix all bugs or implement every nice to have feature.
It can also be interesting to find out why a feature estimated to say 3 points took a whole sprint to be implemented: is there tech debt? was it badly specified? maybe even the dev would have needed help (pair programming, formation, etc.) but didn't ask for it? It's useful for self improvement
It's not, but it's still nice to get a rough estimate, isn't it? It's also useful when you need to prioritize things, because you often cannot fix all bugs or implement every nice to have feature.
It can also be interesting to find out why a feature estimated to say 3 points took a whole sprint to be implemented: is there tech debt? was it badly specified? maybe even the dev would have needed help (pair programming, formation, etc.) but didn't ask for it? It's useful for self improvement
i dont disagree but then comes the question -- how can product effectively create a roadmap without any estimates? which then brings me to the question of whether roadmaps are a waste of time? but senior leadership needs to understand priorities and what the company will be addressing in the next quarter.
so it always folds right back into -- we need to create estimates even if they're completely wrong which seems stupid and insane
so it always folds right back into -- we need to create estimates even if they're completely wrong which seems stupid and insane
> Devs, is your team using story points to estimate work? Why/Why not?
No, but we’re using story points to consume time while still estimating work on hours. Why? Irrational mix of cargo cult practices imposed by management with no articulable rationale.
> Been going back and forth internally to understand the true value of story points in estimating sprints.
Used properly, story points mitigate various problems with estimating intellectual work; basically, teams are empirically better and chunky relative estimates than detailed time-based estimates, but also tend to waste a lot of effort for no return when doing the latter. So, ideally, with SPs you do chunky relative estimates quickly, and over time use statistical analysis tonget a picture of both the expected time and variance (both of which will slowly change over time) that those chunky relative estimates translate into for work items and overall sprint size.
A sibling comment recommends no-estimate flow based development methods, which are often ideal if the dev team has no outside interactions for which estimates matter (or these are rare and unpredictable, so that ad hoc estimation of particular items on demand is more appropriate); if you have such interactions regularly, though, you need the minimum cost way to get estimates accurate to within the limits of available information, and story points, used properly, can be part of a process that provides about the best solution to that available.
As the first part of my comment indicates, story points can be (and often are, IME) used improperly in ways which arr pure waste, too, though.
No, but we’re using story points to consume time while still estimating work on hours. Why? Irrational mix of cargo cult practices imposed by management with no articulable rationale.
> Been going back and forth internally to understand the true value of story points in estimating sprints.
Used properly, story points mitigate various problems with estimating intellectual work; basically, teams are empirically better and chunky relative estimates than detailed time-based estimates, but also tend to waste a lot of effort for no return when doing the latter. So, ideally, with SPs you do chunky relative estimates quickly, and over time use statistical analysis tonget a picture of both the expected time and variance (both of which will slowly change over time) that those chunky relative estimates translate into for work items and overall sprint size.
A sibling comment recommends no-estimate flow based development methods, which are often ideal if the dev team has no outside interactions for which estimates matter (or these are rare and unpredictable, so that ad hoc estimation of particular items on demand is more appropriate); if you have such interactions regularly, though, you need the minimum cost way to get estimates accurate to within the limits of available information, and story points, used properly, can be part of a process that provides about the best solution to that available.
As the first part of my comment indicates, story points can be (and often are, IME) used improperly in ways which arr pure waste, too, though.
I’m doing that for almost 15 years already, and lately I really don’t see value added by it.
Unfortunately I’m still trying to find a way to replace it and get buy in from colleagues and management.
1. It doesn’t really help planning work, unless it’s always the same work. It’s a placebo.
1.1. e.g. team velocity is 20 points , but things are going to work very differently in a sprint with 4 stories of 5 SP and 10 stories of 2 SP. Mainly because the SP includes risk and complexity.
2. Recently saw someone comparing two teams, one doing 80 points the other doing 30. The problem: the former SP range was up to 13, the latter SP range was up to 5, rarely 8. So it still not transferable and meaningless outside it's own context.
3. Not comparable between peers, it doesn't map to the same levels of complexity, amount of work and risk for different people. Mostly people map SP to a range of days or hours and it differs as it's not standardized among peers.
In my team setting I would prefer no estimates and a commitment based approach, but that kinda leaves management without numbers to count besides features and bugs delivered (which is good enough to me).
Unfortunately I’m still trying to find a way to replace it and get buy in from colleagues and management.
1. It doesn’t really help planning work, unless it’s always the same work. It’s a placebo.
1.1. e.g. team velocity is 20 points , but things are going to work very differently in a sprint with 4 stories of 5 SP and 10 stories of 2 SP. Mainly because the SP includes risk and complexity.
2. Recently saw someone comparing two teams, one doing 80 points the other doing 30. The problem: the former SP range was up to 13, the latter SP range was up to 5, rarely 8. So it still not transferable and meaningless outside it's own context.
3. Not comparable between peers, it doesn't map to the same levels of complexity, amount of work and risk for different people. Mostly people map SP to a range of days or hours and it differs as it's not standardized among peers.
In my team setting I would prefer no estimates and a commitment based approach, but that kinda leaves management without numbers to count besides features and bugs delivered (which is good enough to me).
For me the value of story points/planning poker is the conversation that it drives. If I say something is a 3 and someone else says a 7, we then discuss why those numbers. It could potentially be that it's a new hire who has never seen that code before, so it has a lot of unknowns. Or, it could be that see the ramifications of presumed straightforward changes that others miss, and leads to a better understanding of the amount of work.
The only real measure is days.
Everything else is just a way to approach this as effectively as possible.
So the more experienced a team the less they use whistles and the more actual time estimations.
Everything else is just a way to approach this as effectively as possible.
So the more experienced a team the less they use whistles and the more actual time estimations.
We do. You can only point something if you have technical analysis. Having technical analysis performed is extremely important and help to avoid misunderstanding between devs, qa and product.
We have decent estimates, shared understanding and everyone in team can do work.
1. PO would create user stories.
2. Devs volunteer to do tech analysis
3. Team get together and do planning poker.
4. If there are more unknowns, ticket will get deferred/spit
We have decent estimates, shared understanding and everyone in team can do work.
Yes, but we don't do planning poker. We attribute points on stories in 2 situations:
- when we write the specifications for a project, we also create the stories and estimate their points
- when planning the sprint, we quickly estimate them
The points are useful to us because we roughly know how many points we can handle in a sprint, thus we know what we can commit to do in the sprint. We thought of using "short/medium/high" instead of points, but it's harder to get a feeling of whether we can embed one more story in our sprint.
We're not strict on scrum or stuff like that, but estimating properly is still useful when we have a roadmap to stick to. This is how we can know for sure which projects will be removed from the roadmap as the time goes.
- when we write the specifications for a project, we also create the stories and estimate their points
- when planning the sprint, we quickly estimate them
The points are useful to us because we roughly know how many points we can handle in a sprint, thus we know what we can commit to do in the sprint. We thought of using "short/medium/high" instead of points, but it's harder to get a feeling of whether we can embed one more story in our sprint.
We're not strict on scrum or stuff like that, but estimating properly is still useful when we have a roadmap to stick to. This is how we can know for sure which projects will be removed from the roadmap as the time goes.
We don’t.
One thing I want to try is to assign 2 points fixed to all tickets by default and let each individual dev manage their own meaning to the points. So for A it could be 2 points = half day work, for B 2 points = 2 days, and maybe C doesn’t want to use points so it’s all 2 points.
This way you still get a more granular view into the progress, but it’s not annoying for the devs nor it becomes a way to compare “A did more points than B”.
One thing I want to try is to assign 2 points fixed to all tickets by default and let each individual dev manage their own meaning to the points. So for A it could be 2 points = half day work, for B 2 points = 2 days, and maybe C doesn’t want to use points so it’s all 2 points.
This way you still get a more granular view into the progress, but it’s not annoying for the devs nor it becomes a way to compare “A did more points than B”.
I find that discussing if a task is small, medium, or large works the best rather than numerical points that might get too granular.
And as others pointed out, the value is in the conversation it drives and being able to skim a list of tasks to get a rough feel for the scope of the project you're working on.
And as others pointed out, the value is in the conversation it drives and being able to skim a list of tasks to get a rough feel for the scope of the project you're working on.
Last few teams did not but current team does. I can see it helpful if you’re shipping a customer-facing app, you need rough lead time on internal training (customer service), sales for competitive purposes and product for customer expectations.
One day ago:
"Ask HN: Is your team using story points to estimate work? Why or why not?"
6 points, 13 comments
https://news.ycombinator.com/item?id=26963147
"Ask HN: Is your team using story points to estimate work? Why or why not?"
6 points, 13 comments
https://news.ycombinator.com/item?id=26963147
My management forces it, totally useless practice imo.
We use story points, but everyone knows (without ever admitting it publicly) that 1 point = 1 day
Yep. It’s another worthless Agile Cult practice that wastes innumerable man-years.
The team lead wants to test planning poker as well. Thoughts?