I’m in that group and was appalled when I saw this post, but not surprised. I’ve worked in an organization that didn’t weaponize story points, but did weaponize capacity and man hour estimates. Basically, leadership set the standard that each team needed to estimate sub tasks for stories by hour, compared that to capacity (for 6 weeks at a time lol) and used that as an indicator to see if people were working enough or trying to measure it as if the sprint was going to complete. Needless to say, it was very toxic and continued to cause teams to fail.
I've heard your thoughts on why not Story Points. I totally agree on the misuse of them and the problems that causes. I'm not convinced that that makes them bad. If people misuse cars, we don't ban the cars, we ban the people or teach them how to drive better. I completely agree that Velocity should not be used as any kind of performance measure. I'm also a supporter of Troy Magennis' work around cycle time for forecasting. My curiosity is on what you do coach teams on for figuring our how much Capacity they have for a Sprint and how much given work will fill that? Unless the team has evolved to a point where all work is roughly the same size, I've found that looking at past velocity is the best way to determine a guide for how much they can take on in the next sprint. As a strictly team level tool to answer the question "How much work can we take on?", I still find Story Points useful. Cheers
I'm glad you came back at the end and said if you're delivering successfully and customers are happy, then keep doing what you're doing. I don't like absolutes. Todd briefly mentioned it, but I think it's really important to call out, ANY metric when used poorly can be dangerous and is bad for teams. Metrics are supposed to be used to generate a conversation. I use story points, I also use cycle time, monte carlo simulations, and many other metrics. I asked my teams if they like using story points or would be happy if we just stopped. They wanted to keep using them. Do I think you're right about not using them, probably. The probably is, if I'm joining a new company and I see they're doing all the normal anti-patterns of using story points. Is it work the 12-18 months to break EVERYBODY from that pattern? No, definitely not, so using these other things is easier, and they're not used to them so they don't have the anti-pattern built in and I can teach them correctly from the start. However, in my case, I've put that work in, everyone is trained up on how to look at the data and what it means and how not to use story points, so am I going to just stop? No, however, I'm introducing these other metrics over time and maybe the story points will phase out, maybe they won't, we'll see what happens. I'm glad you self-corrected the end though, I sure hope I'm not deemed un-hirable because I know how to use story points and know how to create burn ups and velocity charts and use them correctly. Having all the tools in my toolkit should make me more hirable and not less.
A great way to break the story points pattern is to show how they don't work... I looked at the # of stories in the last few sprints and it was always around six stories of various points being done. When checking with the team and the time spent, the points did not really match the complexity of the work... One evaluated "3" was actually a "8", etc. The team never took 12 stories of 3 points, so it was never evident that the SP approach didn't work. Story Points did not really contribute to the sucess or help, they just seemed to work because the results matched the expectations. Just like Astrology, when it "works" it doesn't mean causation. :) Most teams that say it works are like this, I think. They believe that it works because of the ritual, but in reality, it doesn't. Rare are the unicorns where it works and it has value...
@@AgileforHumans Nice video and I agree that story points are flawed but the flow based metrics and video above seems applicable to Kanban. If you don't use story points, how do you determine how much work can fit into a Sprint?
@@AgileforHumans same question. Hope you can do more videos about forecasting/roadmapping because it is the most difficult question to answer for me thrown by management right now :)
We use story points by the lack of a better solution at this moment. Background: we are a small agency (1 team) that effectively means we work as one team on multiple clients/products in each sprint period. At this moment, we use story points to calculate the capacity put into each sprint. The clients pay for x capacity in each sprint period. Personally, I would like to go without the need of story points or hours, but I do not see a solution for the capacity planning per client. Anyone who has a view on how other agencies do this?
Wow! I've never heard of an industry standard. I would be torn between: a) asking to see proof of that standard, b) wanting to SM that team to save them, and c) walking out of the interview to save my future sanity.
Is there any indicator / metric for team to give ‘‘em understanding of item complexity risks and effort? To get back some predictability for stakeholders, O mean to literally say some kind of items are worthless we can’t do them yet .
Don’t think you answered the question . The 55 number probably came from a SAFe formula for new teams. I also think SP are trash , but I do use them or T-shirt sizing to prompt/trigger conversation in refinement
It is likely SAFe which bakes in a lot of the productivity losses of story points. It is also why SAFe results in teams sandbagging and using creative accounting to make points work. First hand witnessed consultants demonstrating SAFe, and they retrospectived their way to eventually finding excuses to manifest story points out of the air to manufacture an illusion of a constant estimate velocity. Aside from delivering a lousy product every quarter, managers genuinely thought they were witnessing story points having value.
So in Jira, Roadmapping is based on velocity. I've seen some pretty good tools that help with future predictability based on Jira roadmaps. Thoughts? Do we just set every story that is well broken down as 3's and let the tools work that way? 1's, 3's, and 8's?
Guys keep ranting ..This has been awesome ..👌🏽👌🏽 Any tips on breaking the ice with the people still living in that SP world ? What would be the best way to get them to see new perspectives on this ? We did a bbl session on flow metrics and people were still a bit uncomfortable to say the least to drop what they know
Story points have made it into the wild where I work. In two places I have worked, the Scrum Masters/Developers came up with sophisticated calculations of what Story Points mean. Isn't there something in the Agile Manifesto about Simplicity? Anway, I have been fortunate that I have been able to hold off of being made to use Story Points even in a Kanban-like setting. Story Points are like tribbles, once they get into the wild, they are everywhere! I suspect some thought I didn't understand Agile since I refused to use Story Points. Ironically, I am the only employee that is learning something about Agile almost daily. If my workplace eventually succeeds in making me use Story Points, I will show them flow metrics alongside of the Story Points.
I personally would do away with a quantitative approach to story points and use more of a qualitative small, medium or large….. or just do away with points all together. Its gives a very false sense of precision to your ability to predict work!!
I dont think that Ryan and Todd are labeling people. They are saying their opinion which comes through years of experience and struggle. And also they couldn't be more clear. "If you use story points and you successfully delivering and your customer loves you ignore us" So let's leave it at that. Keep going R&T!
Appreciate you listening to the end to see that we did say "If you use story points and you are successfully delivering and your customer loves you ignore us".
I've seen team struggle and be successful with story points. My question is if you don't use story points, how do you answer the question when will the product backlog (as it is) be completed? Management loves that question :)
@@AgileforHumans "When Will It Be Done" does not answer the question in the scenario when you have no historical data. Like when an agile team is bidding on a project.
Story points ARE trash. Waste. Having conversations and doing refinement/planning are things that should happen anyway so that teams are aligned and understand the what and the why before coming up with the how. You don't need story points for that. So what if something is X story points or not - if it's something that needs doing first you do it anyway.
Not true at all. Product Owners make decisions based on ROI for both their organization and the customer. How much can I afford to spend in order to provide value? So, you don't just do things "anyway". You determine what value it will bring, based on it's cost, in comparison to everything else in the backlog. And, while you may not think story points is the best way to determine cost, you need some way to do that, which is a key output of refinement (which you missed in your comment above regarding refinement. Estimating is a KEY output of refinement).
@@scottf9044 sorry I don't mean just do things in any order. What I mean is kinda what you said: things that bring the most value to the customer. I'm not sure how you can link that to story points. What I'm saying is you can do all that with something like user story mapping and release slicing. Estimation is something you are doing whether you realise it or not when you're refining and discussing the work. It doesn't mean you attribute story points, t-shirt sizes or dog breeds.
When management starts to talk about velocity I just tell teams to multiple all their story points by 10. So, use 10, 20, 30, 50, 80, etc. Since it's all about relativity the scale still works. And it drives the point home that it's use is for the team only for planning purposes. But, I do agree that MOST teams don't have an understanding of story points and relativity. They're just throwing numbers out.
@@AgileforHumans I kindly disagree :) There are tools for beginners that are no longer useful for experienced people. Story points to me is a tool for beginners to build shared understanding and experience the benefits of it. So use it, learn and grow, then trash it once you are able to generate enough shared understanding more "naturally" whithout support of a tool. My opinion though. But I agree that bold statement such as "it's trash" is interesting to generate discussion on why are we working "this way" or "that way".
Conversely, it could be more interesting to start with a discussion on Work Item Age. What is actually happening to something that we are currently working on? Can anyone help to get it moving? Is there a signal for trouble ahead if it is aging disproportionately? When it comes to planning, why not look at Throughput and forecast a probability for what we anticipate we could bring into a Sprint? " 85% of the time we are finishing {x} number of items in a Sprint". Remembering, that this historical data is only ONE of many inputs to planning (retro improvements, definition of done, the work we are facing, etc.). Looking at the flow metrics are much more relatable and don't require teaching a method that is woefully misunderstood and mis-practiced. I just think there are far better options that are more relevant to today than wasting the time teaching story points. -Todd
@@AgileforHumans I do believe there is value in discussing and aligning on the anticipated complexity of an item upfront of starting working on it, especially in teams with low maturity. That's also why the unit of sizing does not really matter, as long as there is a limit that triggers a "We need to split / reduce scope" reflex. But I agree on the flow metrics and the 85th percentile of items done per sprint are more valuable tools for planning. However, having people understand flow metrics and monte carlo simulation and percentiles etc... is, from my experience, not so straightforward. Speaking from experience as an agile coach in a big tech corp, they put so much focus on predictability that we ended up with green/red dashboards based on monte carlo that was basicaly saying: this epic will likely be finished at this date. PMs were told to "make those dashboard green!" but did not had the understanding of the principles behind, so the game was to make things green (i.e. lets split an epic into 2, and tada, it's green), not to manage flow to deliver value more regularly. All this to say that flow metrics can be trash as well. Alex
So you really want to “stop the harmfulness”? Maybe stop labeling people who disagree with your points, and/or point out inconsistencies and gaps in your thinking, as “favorite haters”. Or even the title here: “story points are trash”. Resorting to that sort of name-calling equates to a loud declaration that you can’t engage on the issues themselves.
I’m in that group and was appalled when I saw this post, but not surprised. I’ve worked in an organization that didn’t weaponize story points, but did weaponize capacity and man hour estimates. Basically, leadership set the standard that each team needed to estimate sub tasks for stories by hour, compared that to capacity (for 6 weeks at a time lol) and used that as an indicator to see if people were working enough or trying to measure it as if the sprint was going to complete. Needless to say, it was very toxic and continued to cause teams to fail.
Thank you for your story and contribution.
Story points are trash, some of the conversation that happens when you are estimating them are useful.
Agreed! Poker planning can be a useful analysis tool.
Story points, as it stands today, have become a way for management to micromanage and judge teams performance.
Not only teams, individuals too.
I've heard your thoughts on why not Story Points. I totally agree on the misuse of them and the problems that causes. I'm not convinced that that makes them bad. If people misuse cars, we don't ban the cars, we ban the people or teach them how to drive better. I completely agree that Velocity should not be used as any kind of performance measure. I'm also a supporter of Troy Magennis' work around cycle time for forecasting.
My curiosity is on what you do coach teams on for figuring our how much Capacity they have for a Sprint and how much given work will fill that? Unless the team has evolved to a point where all work is roughly the same size, I've found that looking at past velocity is the best way to determine a guide for how much they can take on in the next sprint. As a strictly team level tool to answer the question "How much work can we take on?", I still find Story Points useful.
Cheers
Did I miss the explanation on why they are trash? Assuming they are not weaponized. Or is it the weaponizing that is trash?
I'm glad you came back at the end and said if you're delivering successfully and customers are happy, then keep doing what you're doing. I don't like absolutes. Todd briefly mentioned it, but I think it's really important to call out, ANY metric when used poorly can be dangerous and is bad for teams. Metrics are supposed to be used to generate a conversation. I use story points, I also use cycle time, monte carlo simulations, and many other metrics. I asked my teams if they like using story points or would be happy if we just stopped. They wanted to keep using them. Do I think you're right about not using them, probably. The probably is, if I'm joining a new company and I see they're doing all the normal anti-patterns of using story points. Is it work the 12-18 months to break EVERYBODY from that pattern? No, definitely not, so using these other things is easier, and they're not used to them so they don't have the anti-pattern built in and I can teach them correctly from the start. However, in my case, I've put that work in, everyone is trained up on how to look at the data and what it means and how not to use story points, so am I going to just stop? No, however, I'm introducing these other metrics over time and maybe the story points will phase out, maybe they won't, we'll see what happens. I'm glad you self-corrected the end though, I sure hope I'm not deemed un-hirable because I know how to use story points and know how to create burn ups and velocity charts and use them correctly. Having all the tools in my toolkit should make me more hirable and not less.
Great response! Thank you for taking the time we agree with what you said.
A great way to break the story points pattern is to show how they don't work... I looked at the # of stories in the last few sprints and it was always around six stories of various points being done. When checking with the team and the time spent, the points did not really match the complexity of the work... One evaluated "3" was actually a "8", etc. The team never took 12 stories of 3 points, so it was never evident that the SP approach didn't work.
Story Points did not really contribute to the sucess or help, they just seemed to work because the results matched the expectations. Just like Astrology, when it "works" it doesn't mean causation. :)
Most teams that say it works are like this, I think. They believe that it works because of the ritual, but in reality, it doesn't. Rare are the unicorns where it works and it has value...
I agree. Perhaps you can dive a little more into the Flow Based Metrics.
We have some info on our Fixing Your Kanban channel: ruclips.net/p/PL9uyGDiy_ChVfUxjc5gowNg0wW0gLFnx6
@@AgileforHumans Nice video and I agree that story points are flawed but the flow based metrics and video above seems applicable to Kanban. If you don't use story points, how do you determine how much work can fit into a Sprint?
@@AgileforHumans same question. Hope you can do more videos about forecasting/roadmapping because it is the most difficult question to answer for me thrown by management right now :)
We use story points by the lack of a better solution at this moment.
Background: we are a small agency (1 team) that effectively means we work as one team on multiple clients/products in each sprint period. At this moment, we use story points to calculate the capacity put into each sprint. The clients pay for x capacity in each sprint period.
Personally, I would like to go without the need of story points or hours, but I do not see a solution for the capacity planning per client.
Anyone who has a view on how other agencies do this?
Wow! I've never heard of an industry standard. I would be torn between: a) asking to see proof of that standard, b) wanting to SM that team to save them, and c) walking out of the interview to save my future sanity.
Thank you guys! Very helpful
we've tried story points and time estimates and we never managed to deliver 100% of our sprint
Is there any indicator / metric for team to give ‘‘em understanding of item complexity risks and effort? To get back some predictability for stakeholders, O mean to literally say some kind of items are worthless we can’t do them yet .
Don’t think you answered the question . The 55 number probably came from a SAFe formula for new teams.
I also think SP are trash , but I do use them or T-shirt sizing to prompt/trigger conversation in refinement
It is likely SAFe which bakes in a lot of the productivity losses of story points. It is also why SAFe results in teams sandbagging and using creative accounting to make points work.
First hand witnessed consultants demonstrating SAFe, and they retrospectived their way to eventually finding excuses to manifest story points out of the air to manufacture an illusion of a constant estimate velocity.
Aside from delivering a lousy product every quarter, managers genuinely thought they were witnessing story points having value.
Yikes! And this is exactly why we've taken the stance that we have on story points. The story you told is too familiar...
So in Jira, Roadmapping is based on velocity. I've seen some pretty good tools that help with future predictability based on Jira roadmaps. Thoughts? Do we just set every story that is well broken down as 3's and let the tools work that way? 1's, 3's, and 8's?
Guys keep ranting ..This has been awesome ..👌🏽👌🏽
Any tips on breaking the ice with the people still living in that SP world ?
What would be the best way to get them to see new perspectives on this ?
We did a bbl session on flow metrics and people were still a bit uncomfortable to say the least to drop what they know
Comparing two teams based on velocity that's makes even more harder
Story points have made it into the wild where I work. In two places I have worked, the Scrum Masters/Developers came up with sophisticated calculations of what Story Points mean. Isn't there something in the Agile Manifesto about Simplicity?
Anway, I have been fortunate that I have been able to hold off of being made to use Story Points even in a Kanban-like setting. Story Points are like tribbles, once they get into the wild, they are everywhere! I suspect some thought I didn't understand Agile since I refused to use Story Points. Ironically, I am the only employee that is learning something about Agile almost daily. If my workplace eventually succeeds in making me use Story Points, I will show them flow metrics alongside of the Story Points.
I personally would do away with a quantitative approach to story points and use more of a qualitative small, medium or large….. or just do away with points all together. Its gives a very false sense of precision to your ability to predict work!!
Great plan!
I dont think that Ryan and Todd are labeling people. They are saying their opinion which comes through years of experience and struggle. And also they couldn't be more clear. "If you use story points and you successfully delivering and your customer loves you ignore us" So let's leave it at that. Keep going R&T!
Appreciate you listening to the end to see that we did say "If you use story points and you are successfully delivering and your customer loves you ignore us".
I've seen team struggle and be successful with story points. My question is if you don't use story points, how do you answer the question when will the product backlog (as it is) be completed? Management loves that question :)
We love Dan Vacanti's book "When Will It Be Done" for this. We've done some vids with him here: ruclips.net/p/PL9uyGDiy_ChVfUxjc5gowNg0wW0gLFnx6
@@AgileforHumans "When Will It Be Done" does not answer the question in the scenario when you have no historical data. Like when an agile team is bidding on a project.
Story points ARE trash. Waste. Having conversations and doing refinement/planning are things that should happen anyway so that teams are aligned and understand the what and the why before coming up with the how. You don't need story points for that.
So what if something is X story points or not - if it's something that needs doing first you do it anyway.
Not true at all. Product Owners make decisions based on ROI for both their organization and the customer. How much can I afford to spend in order to provide value? So, you don't just do things "anyway". You determine what value it will bring, based on it's cost, in comparison to everything else in the backlog. And, while you may not think story points is the best way to determine cost, you need some way to do that, which is a key output of refinement (which you missed in your comment above regarding refinement. Estimating is a KEY output of refinement).
@@scottf9044 sorry I don't mean just do things in any order. What I mean is kinda what you said: things that bring the most value to the customer. I'm not sure how you can link that to story points. What I'm saying is you can do all that with something like user story mapping and release slicing.
Estimation is something you are doing whether you realise it or not when you're refining and discussing the work. It doesn't mean you attribute story points, t-shirt sizes or dog breeds.
When management starts to talk about velocity I just tell teams to multiple all their story points by 10. So, use 10, 20, 30, 50, 80, etc. Since it's all about relativity the scale still works. And it drives the point home that it's use is for the team only for planning purposes. But, I do agree that MOST teams don't have an understanding of story points and relativity. They're just throwing numbers out.
Poor use of story points is trash. Don't blame the tool, as always.
There are bad tools out there... There are also antiquated tools like story points.
@@AgileforHumans I kindly disagree :) There are tools for beginners that are no longer useful for experienced people. Story points to me is a tool for beginners to build shared understanding and experience the benefits of it. So use it, learn and grow, then trash it once you are able to generate enough shared understanding more "naturally" whithout support of a tool. My opinion though. But I agree that bold statement such as "it's trash" is interesting to generate discussion on why are we working "this way" or "that way".
Conversely, it could be more interesting to start with a discussion on Work Item Age. What is actually happening to something that we are currently working on? Can anyone help to get it moving? Is there a signal for trouble ahead if it is aging disproportionately?
When it comes to planning, why not look at Throughput and forecast a probability for what we anticipate we could bring into a Sprint? " 85% of the time we are finishing {x} number of items in a Sprint". Remembering, that this historical data is only ONE of many inputs to planning (retro improvements, definition of done, the work we are facing, etc.).
Looking at the flow metrics are much more relatable and don't require teaching a method that is woefully misunderstood and mis-practiced. I just think there are far better options that are more relevant to today than wasting the time teaching story points.
-Todd
@@AgileforHumans
I do believe there is value in discussing and aligning on the anticipated complexity of an item upfront of starting working on it, especially in teams with low maturity. That's also why the unit of sizing does not really matter, as long as there is a limit that triggers a "We need to split / reduce scope" reflex.
But I agree on the flow metrics and the 85th percentile of items done per sprint are more valuable tools for planning.
However, having people understand flow metrics and monte carlo simulation and percentiles etc... is, from my experience, not so straightforward.
Speaking from experience as an agile coach in a big tech corp, they put so much focus on predictability that we ended up with green/red dashboards based on monte carlo that was basicaly saying: this epic will likely be finished at this date. PMs were told to "make those dashboard green!" but did not had the understanding of the principles behind, so the game was to make things green (i.e. lets split an epic into 2, and tada, it's green), not to manage flow to deliver value more regularly.
All this to say that flow metrics can be trash as well.
Alex
Any metric that's used for the sake of performance loses it's ability to tell you anything.
So you really want to “stop the harmfulness”? Maybe stop labeling people who disagree with your points, and/or point out inconsistencies and gaps in your thinking, as “favorite haters”. Or even the title here: “story points are trash”.
Resorting to that sort of name-calling equates to a loud declaration that you can’t engage on the issues themselves.
They're just playing the YT game, you can't blame them for that.