The usefulness of SP is in communicating opinions during estimation. Like one person can say that a task is small and another one says it's large. When each of them explains what their opinions are based on, they share knowledge.
If it works for you, great! I think "small" doesn't need discussion and if someone notices a "large" then just discuss it. No need for story points really 🤷♂️
I’ve never used story points as an estimation of how long something will take, but how complex a piece of work is. This can then be used as an indicator of the quality of your code. If something of equal complexity is taking longer and longer then your software is becoming hard to change. The main reason for this is because more and more logic is just being piled on to existing code without it being continuously refactored to make it easy to change. Decreasing velocity means your code base is getting smelly.
Good points, though I prefer not to measure these things. Usually everyone on the team knows quite well when complexity is reaching that bad point. So I think the story points are not so much the means to detect the problem, but instead a possible, but maybe not the best, way to communicate it.
As a developer, story points are dysfunctional in my team. Yet the tech lead and product owner insist on using them. Any tips on dealing with that? (1SP = 1 day, and I'm held accountable to that as a due date even if i estimated differently during planning poker because the majority estimate wins. And we never go back and look at how difficult tickets actually were to what was estimated. Etc etc...)
Address the root cause: you should not be held accountable for someone else's estimate. And if you don't give an estimate, the discussion has to move to a more meaningful place. I think I'll do a video on how to argue these points soon 🤔
Back when I was a PO I would explicitly leave the discussion when story points or any other estimations was brought up. I told my teams that I just wanted an answer to the question: Is this goal achievable in the next sprint. If not, then we re-worked the goal. If yes, we're done. Planning is over. I didn't care how teams estimated whether or not a sprint goal was achievable, I just cared that they gave me an answer. My plannings usually lasted only 10-15 minutes because I always made sure to include investigations for future sprints as a part of the expected work which meant that when we moved into the next planning we already knew how to technically solve the next set of potential goals without having any boring refinement meetings.
@@JohnDoe-sq5nv But then the quality of the feature resides on if it could be done in a sprint, not whether or not it delivered what the customer actually desired (which could take longer)?
@@magne6049 Depends. And this is also a place where Scrum itself breaks against reality and why it might not always be a suitable framework with its consistent sprints. Scrum states that every sprint should result in a potentially releasable increment, in practice that might not be possible but a scrum breaking work around is to simply communicate this to the stakeholders/customers and split the feature into as many steps as needed where the steps themselves at least provide value.
Ideally I wouldn't use estimates, and would instead build trust with the customer with frequent releases that deliver value. Estimates are so BS at my current workplace. Deadlines are completely artificial. The client often takes months, even a year, to complete their own testing on a feature before going live with it. So when internal product people put pressure on us to deliver it's nonsense 😂
There's something to a healthy amount of pressure, but your team should be in control of it preferably. No pressure and you'll go too lax, a little bit of pressure is fine, but if it's at the cost of quality/ burnout/ etc. it's too costly
IMHO all these arguments are not arguing against Story Points itself, but describe a bad usage of them. IMHO you are not supposed to carry your SP estimates outside of the team. You dont communicate them and you dont use them to compare to other teams. It's also not a usefull information for steakholders. Rather should they be interested in when the feature they are interested is going to be delivered, which usually corresponds to a certain sprint. Storypoints are a tool to estimate work inside the team and to be used to prioritize tasks based on thos estimates. They are a tool to compare task complexity, not time required to do the task.
That's the theory at least. I've never encountered a team that could keep them internal though. You still have to reason with stakeholders and if it works for you to base that discussion on storypoints without exposing them, awesome! Personally, I find that too hard and instead opt for the alternatives.
@@FranklyDeveloping I didnt get any alternative from that video. Not estimating? That's just chaos. How does that even work? You just pull a Blizzard and say it's done when it's done? How does that even fly with stakeholders? How would you know when a task spirals out of control, effor wise? I am curious about how this is supposed to work. From the video I only get some, imho. very weak excuses for not using Story Points but not really an alternative.
Also, how would you estimate costs for a customer without doing even some rough estimation? How woud you reprioritize tasks when you dont know if the effort / value ration is bad for a todo?
I've planned to make another video on this. But yes, not estimating is a controversial topic. I stopped doing it years ago and actually find it a lot less chaotic. That may not be true for everyone though.
The usefulness of SP is in communicating opinions during estimation. Like one person can say that a task is small and another one says it's large. When each of them explains what their opinions are based on, they share knowledge.
If it works for you, great! I think "small" doesn't need discussion and if someone notices a "large" then just discuss it. No need for story points really 🤷♂️
I’ve never used story points as an estimation of how long something will take, but how complex a piece of work is. This can then be used as an indicator of the quality of your code. If something of equal complexity is taking longer and longer then your software is becoming hard to change. The main reason for this is because more and more logic is just being piled on to existing code without it being continuously refactored to make it easy to change. Decreasing velocity means your code base is getting smelly.
Good points, though I prefer not to measure these things. Usually everyone on the team knows quite well when complexity is reaching that bad point. So I think the story points are not so much the means to detect the problem, but instead a possible, but maybe not the best, way to communicate it.
As a developer, story points are dysfunctional in my team. Yet the tech lead and product owner insist on using them.
Any tips on dealing with that? (1SP = 1 day, and I'm held accountable to that as a due date even if i estimated differently during planning poker because the majority estimate wins. And we never go back and look at how difficult tickets actually were to what was estimated. Etc etc...)
Address the root cause: you should not be held accountable for someone else's estimate. And if you don't give an estimate, the discussion has to move to a more meaningful place. I think I'll do a video on how to argue these points soon 🤔
Back when I was a PO I would explicitly leave the discussion when story points or any other estimations was brought up. I told my teams that I just wanted an answer to the question: Is this goal achievable in the next sprint. If not, then we re-worked the goal. If yes, we're done. Planning is over. I didn't care how teams estimated whether or not a sprint goal was achievable, I just cared that they gave me an answer.
My plannings usually lasted only 10-15 minutes because I always made sure to include investigations for future sprints as a part of the expected work which meant that when we moved into the next planning we already knew how to technically solve the next set of potential goals without having any boring refinement meetings.
@@JohnDoe-sq5nv But then the quality of the feature resides on if it could be done in a sprint, not whether or not it delivered what the customer actually desired (which could take longer)?
@@magne6049 Depends. And this is also a place where Scrum itself breaks against reality and why it might not always be a suitable framework with its consistent sprints. Scrum states that every sprint should result in a potentially releasable increment, in practice that might not be possible but a scrum breaking work around is to simply communicate this to the stakeholders/customers and split the feature into as many steps as needed where the steps themselves at least provide value.
solid points, but drop the music!
I got better with editing to a fast pace, so there aren't a lot of breaks now.. I guess you're right, the music isn't really needed anymore.
Ideally I wouldn't use estimates, and would instead build trust with the customer with frequent releases that deliver value.
Estimates are so BS at my current workplace. Deadlines are completely artificial. The client often takes months, even a year, to complete their own testing on a feature before going live with it. So when internal product people put pressure on us to deliver it's nonsense 😂
There's something to a healthy amount of pressure, but your team should be in control of it preferably. No pressure and you'll go too lax, a little bit of pressure is fine, but if it's at the cost of quality/ burnout/ etc. it's too costly
Story points make me wish I went to dental school.
Makes me wonder what important concept you would learn there that helps with story points? 🤔
IMHO all these arguments are not arguing against Story Points itself, but describe a bad usage of them. IMHO you are not supposed to carry your SP estimates outside of the team. You dont communicate them and you dont use them to compare to other teams. It's also not a usefull information for steakholders. Rather should they be interested in when the feature they are interested is going to be delivered, which usually corresponds to a certain sprint. Storypoints are a tool to estimate work inside the team and to be used to prioritize tasks based on thos estimates. They are a tool to compare task complexity, not time required to do the task.
That's the theory at least. I've never encountered a team that could keep them internal though. You still have to reason with stakeholders and if it works for you to base that discussion on storypoints without exposing them, awesome! Personally, I find that too hard and instead opt for the alternatives.
@@FranklyDeveloping I didnt get any alternative from that video. Not estimating? That's just chaos. How does that even work? You just pull a Blizzard and say it's done when it's done? How does that even fly with stakeholders? How would you know when a task spirals out of control, effor wise? I am curious about how this is supposed to work. From the video I only get some, imho. very weak excuses for not using Story Points but not really an alternative.
Also, how would you estimate costs for a customer without doing even some rough estimation? How woud you reprioritize tasks when you dont know if the effort / value ration is bad for a todo?
I've planned to make another video on this. But yes, not estimating is a controversial topic. I stopped doing it years ago and actually find it a lot less chaotic. That may not be true for everyone though.