Story points are part of the daily bullshit bingo that is modern software development. IMHO no matter how much people deny it, story points are in fact a cost & time estimation. This seems somehow to be a very emotional topic for some of the dogmatic process nazis that plague this industry. I hate dogmatic application of anything and the standard argument with scrum fan boys is that world + dog is doing it wrong and that the world would be a better place if only they would do it "right" (for very loosely defined & elusive notions of right). This usually seems to involve insane amounts of meetings, post its, and people who don't write particularly impressive amounts of code getting to join in on the debate of what the fuck are we actually building and how.
The only budget developers really have to spend is their time, which means cost estimations and time estimations are the same thing. Freelancers bill per time unit, not per story point. Billing per story point is not a thing in this industry. The burn rate of your project is measured in $$. This literally is the amount of salary per time unit (plus typically some minor expenses). So, story points are really cost estimations which really boil down to just how long is this going to FFing take what and can we do within the typically fixed duration & cost of a single sprint.
This in turn is really a function of risk and predictability. Something low risk and predictable equals a low amount of points. If you have predictable, more of the same type work that takes 20 points, it is time to refactor your code base because you are likely doing a lot of the same things in a very inefficient way over and over again. If it starts feeling like routine, you are probably doing it wrong. If on the other hand you have a lot of uncertainty around a topic, usually you need to do a spike, which is gasp a time boxed effort to figure out the best way to do things.
You can work on something for a few hours, a few days, or longer. The longer the period, the higher the risk, the more points. That simple. 1 point means STFU and let me do my job, this meeting is taking up more time than the actual work we're planning; can we please move on to something interesting. 2 points means about twice that amount of work which is still barely worth having meetings about (i.e. doubling the cost of the task). 3 means I should be able to do it before lunch if you stop interrupting me and I should be able to do another 5 after lunch. 8 means that a good uninterrupted day (rare) of focused time should get the job done but there's a risk it will spill over.
As PMs well know, anything over 13-20 means they fucked up with their planning because devs are essentially telling them it might take most of the sprint, which is risky. The bartering that happens when you basically tell a PM that the plan sucks by estimating something at 20 points or more is just about the most productive thing that can happen in an estimation session. Usually it involves reducing the ambition level until it lines up with reality by breaking things down into more predictable things or deciding to just go for it and wing it (happens surprisingly often).
Now both product management and devs know all this, which basically means planning sessions are really about PMs trying to figure out how badly they want to compromise their cycle times by overloading it with too much work (rookie mistake).
Based on what I've seen, product management is typically a junior management role and you see a lot of the same mistakes being made over and over again. Often the reasons you end up doing scrum to begin with are because PMs insist on this. Which, if you've followed any Scrum training you should know is not a valid reason. PMs love story points mainly because it allows them to dumb down progress to a simple graph for senior management. It's literally the illusion of progress. Bragging about points shipped is a thing.
Basically, it goes down hill from there. Because you end up doing estimation sessions because the PM wants to boast about his team's velocity. In most teams I've worked with velocity charts are not actually a thing. It's one of those mythical artifacts that either don't happen at all or are getting exactly the wrong people excited for the wrong reasons. It seems to be mostly an aspirational thing however.
These are some of the reasons, I simply practice Kanban regardless of the process around me. I decide in the morning what I work on based on what needs to be done most urgently. Sometimes that aligns with what was planned two weeks ago but a reality of my life seems to be dealing with all the unplanned, unestimated super urgent stuff happening all the time. I'm most productive when I can anticipate some of that and squeeze in unscheduled bits of work that facilitate those things. E.g. some strategic refactoring, building test infrastructure, doing little spikes, and other stuff PMs prefer to pretend has low business value that is actually about saving their ass down the line.
You make some good points (dogmatic application of anything is a mistake). But I believe you understood the whole story point thing wrong. Probably because you worked in teams that didn't make good use of it/didn't understand the benefit.
The main idea behind story points is doing comparative estimation because it has been proven to be more effective than absolute estimation (even for the most experienced). That's it.
But the thing I disliked the most about your comment was the sentence: "I simply practice Kanban regardless of the process around me". This tells me you're probably not a very good team player even though you claim to be "saving their assess down the line". Sorry, but I wouldn't like you in my team with that attitude.
All teams I've ever worked with, in fact. Exactly my point. It's always some other teams that are "doing it right" and it doesn't work "because you are doing it wrong" seems to be a common way to dismiss criticism by agile fan boys. There is no right way. Story points are cost estimations and divide and conquer is the name of the game that is being played. Break things down enough and you manage the error margin.
I actually have an academic background in software engineering so I'm somewhat more perceptive when I hear BS than some others in this industry. So, when you say "it has been proven that", I say actually no: there is no such thing as proof here. The only thing that has been proven conclusively about scrum is that in a tightly controlled experiment involving mostly student volunteers that it is not completely actively harmful and in fact may be slightly better than not having any other (unspecified) systematic approach to development at all.
I'm deliberately exaggerating but I've read most of the key papers in this space. Solid research by the way, and you are of course free to interpret the conclusions as you please but, in fact, not much at all has been proven about scrum and agile and what is often portrayed as empirical research is in fact anecdotes and marketing material promoted by for profit agile consultants that typically have a commercial interest in highlighting their presumed success stories and covering up the fact that actually the relative proportion of projects succeeding vs. succeeding in our industry is a remarkable stable thing for decades. Proper empirical research is a rare thing for cost reasons and also companies tend to not be as open about their failures and publishing all the dirty laundry around that.
I've survived a few hype cycles and the only thing that is certain is that there will always be a next one.
Regarding your team and me, you may want to consider that there are those that speak up and those that don't but would like to. All I'm saying is, don't shoot the messenger: you likely have people on your team already that maybe wouldn't disagree with the above. I talk to lots of people with reservations on this front that maybe are not in a position to call out their PMs on the agile BS they are being subjected to on a daily basis.
You misunderstood what I said. I said comparative estimation has been proven to be more effective than absolute estimation. I didn't say that scrum/agile has been proven anything and I don't claim such thing. Whatever works for your team is good, call it whatever. In my opinion, Scrum/Agile provides some guidelines and some empirically tested tools/resources to deal with common issues that developer teams face and it's one of the best starting points known so far.
And I agree that "you have been doing it wrong" is a common response. But is not a way to dismiss criticism, it is an attempt to say that anything that you apply incorrectly will lead to wrong results and by the looks of your comment you/your company applied or understood agile in the wrong way. Thus, you should be criticising your specific way of applying those rules not the whole methodology. Or you could criticise the way that many companies dogmatically apply scrum, of course.
I also have an academic background in software engineering (which means nothing, by the way, it is an authority fallacy) and I also think there is tons of bullshit, I completely agree with you here.
Also, yes, Scrum might be one of those "hype cycles", so what? It means people trying new stuff and techniques, trying to improve themselves and their processes? Seems to me like a good thing to happen.
Finally, what I criticised was your attitude of "I know it better than the rest, I would do it my way not caring about what others do/want". Not only I would not criticise people who "speak up" and give their opinion against our processes, I would love if they did. It would give us great opportunities to improve ourselves. And I constantly try to avoid having an environment where people are not "in position to call out their PMs".
Completely agree. Story points was definitely not invented by some software developer, it's manager's bullshit created to make illussion of understand to things which they are lazy and incompetent to understand. It only put useless bothering into software development process. I have created for myself such Story points anti-bothering table:
Task size Effort Story points
XS 1-2 days 1
S 2-5 days 2
M 1-2 weeks 3
L 2-4 weeks 5
XL 4-8 weeks 8
XXL >8 weeks 13
So I don't have to bother with that fck story points during scrum planning any longer.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Story points are part of the daily bullshit bingo that is modern software development. IMHO no matter how much people deny it, story points are in fact a cost & time estimation. This seems somehow to be a very emotional topic for some of the dogmatic process nazis that plague this industry. I hate dogmatic application of anything and the standard argument with scrum fan boys is that world + dog is doing it wrong and that the world would be a better place if only they would do it "right" (for very loosely defined & elusive notions of right). This usually seems to involve insane amounts of meetings, post its, and people who don't write particularly impressive amounts of code getting to join in on the debate of what the fuck are we actually building and how.
The only budget developers really have to spend is their time, which means cost estimations and time estimations are the same thing. Freelancers bill per time unit, not per story point. Billing per story point is not a thing in this industry. The burn rate of your project is measured in $$. This literally is the amount of salary per time unit (plus typically some minor expenses). So, story points are really cost estimations which really boil down to just how long is this going to FFing take what and can we do within the typically fixed duration & cost of a single sprint.
This in turn is really a function of risk and predictability. Something low risk and predictable equals a low amount of points. If you have predictable, more of the same type work that takes 20 points, it is time to refactor your code base because you are likely doing a lot of the same things in a very inefficient way over and over again. If it starts feeling like routine, you are probably doing it wrong. If on the other hand you have a lot of uncertainty around a topic, usually you need to do a spike, which is gasp a time boxed effort to figure out the best way to do things.
You can work on something for a few hours, a few days, or longer. The longer the period, the higher the risk, the more points. That simple. 1 point means STFU and let me do my job, this meeting is taking up more time than the actual work we're planning; can we please move on to something interesting. 2 points means about twice that amount of work which is still barely worth having meetings about (i.e. doubling the cost of the task). 3 means I should be able to do it before lunch if you stop interrupting me and I should be able to do another 5 after lunch. 8 means that a good uninterrupted day (rare) of focused time should get the job done but there's a risk it will spill over.
As PMs well know, anything over 13-20 means they fucked up with their planning because devs are essentially telling them it might take most of the sprint, which is risky. The bartering that happens when you basically tell a PM that the plan sucks by estimating something at 20 points or more is just about the most productive thing that can happen in an estimation session. Usually it involves reducing the ambition level until it lines up with reality by breaking things down into more predictable things or deciding to just go for it and wing it (happens surprisingly often).
Now both product management and devs know all this, which basically means planning sessions are really about PMs trying to figure out how badly they want to compromise their cycle times by overloading it with too much work (rookie mistake).
Based on what I've seen, product management is typically a junior management role and you see a lot of the same mistakes being made over and over again. Often the reasons you end up doing scrum to begin with are because PMs insist on this. Which, if you've followed any Scrum training you should know is not a valid reason. PMs love story points mainly because it allows them to dumb down progress to a simple graph for senior management. It's literally the illusion of progress. Bragging about points shipped is a thing.
Basically, it goes down hill from there. Because you end up doing estimation sessions because the PM wants to boast about his team's velocity. In most teams I've worked with velocity charts are not actually a thing. It's one of those mythical artifacts that either don't happen at all or are getting exactly the wrong people excited for the wrong reasons. It seems to be mostly an aspirational thing however.
These are some of the reasons, I simply practice Kanban regardless of the process around me. I decide in the morning what I work on based on what needs to be done most urgently. Sometimes that aligns with what was planned two weeks ago but a reality of my life seems to be dealing with all the unplanned, unestimated super urgent stuff happening all the time. I'm most productive when I can anticipate some of that and squeeze in unscheduled bits of work that facilitate those things. E.g. some strategic refactoring, building test infrastructure, doing little spikes, and other stuff PMs prefer to pretend has low business value that is actually about saving their ass down the line.
You make some good points (dogmatic application of anything is a mistake). But I believe you understood the whole story point thing wrong. Probably because you worked in teams that didn't make good use of it/didn't understand the benefit.
The main idea behind story points is doing comparative estimation because it has been proven to be more effective than absolute estimation (even for the most experienced). That's it.
But the thing I disliked the most about your comment was the sentence: "I simply practice Kanban regardless of the process around me". This tells me you're probably not a very good team player even though you claim to be "saving their assess down the line". Sorry, but I wouldn't like you in my team with that attitude.
All teams I've ever worked with, in fact. Exactly my point. It's always some other teams that are "doing it right" and it doesn't work "because you are doing it wrong" seems to be a common way to dismiss criticism by agile fan boys. There is no right way. Story points are cost estimations and divide and conquer is the name of the game that is being played. Break things down enough and you manage the error margin.
I actually have an academic background in software engineering so I'm somewhat more perceptive when I hear BS than some others in this industry. So, when you say "it has been proven that", I say actually no: there is no such thing as proof here. The only thing that has been proven conclusively about scrum is that in a tightly controlled experiment involving mostly student volunteers that it is not completely actively harmful and in fact may be slightly better than not having any other (unspecified) systematic approach to development at all.
I'm deliberately exaggerating but I've read most of the key papers in this space. Solid research by the way, and you are of course free to interpret the conclusions as you please but, in fact, not much at all has been proven about scrum and agile and what is often portrayed as empirical research is in fact anecdotes and marketing material promoted by for profit agile consultants that typically have a commercial interest in highlighting their presumed success stories and covering up the fact that actually the relative proportion of projects succeeding vs. succeeding in our industry is a remarkable stable thing for decades. Proper empirical research is a rare thing for cost reasons and also companies tend to not be as open about their failures and publishing all the dirty laundry around that.
I've survived a few hype cycles and the only thing that is certain is that there will always be a next one.
Regarding your team and me, you may want to consider that there are those that speak up and those that don't but would like to. All I'm saying is, don't shoot the messenger: you likely have people on your team already that maybe wouldn't disagree with the above. I talk to lots of people with reservations on this front that maybe are not in a position to call out their PMs on the agile BS they are being subjected to on a daily basis.
You misunderstood what I said. I said comparative estimation has been proven to be more effective than absolute estimation. I didn't say that scrum/agile has been proven anything and I don't claim such thing. Whatever works for your team is good, call it whatever. In my opinion, Scrum/Agile provides some guidelines and some empirically tested tools/resources to deal with common issues that developer teams face and it's one of the best starting points known so far.
And I agree that "you have been doing it wrong" is a common response. But is not a way to dismiss criticism, it is an attempt to say that anything that you apply incorrectly will lead to wrong results and by the looks of your comment you/your company applied or understood agile in the wrong way. Thus, you should be criticising your specific way of applying those rules not the whole methodology. Or you could criticise the way that many companies dogmatically apply scrum, of course.
I also have an academic background in software engineering (which means nothing, by the way, it is an authority fallacy) and I also think there is tons of bullshit, I completely agree with you here.
Also, yes, Scrum might be one of those "hype cycles", so what? It means people trying new stuff and techniques, trying to improve themselves and their processes? Seems to me like a good thing to happen.
Finally, what I criticised was your attitude of "I know it better than the rest, I would do it my way not caring about what others do/want". Not only I would not criticise people who "speak up" and give their opinion against our processes, I would love if they did. It would give us great opportunities to improve ourselves. And I constantly try to avoid having an environment where people are not "in position to call out their PMs".
Completely agree. Story points was definitely not invented by some software developer, it's manager's bullshit created to make illussion of understand to things which they are lazy and incompetent to understand. It only put useless bothering into software development process. I have created for myself such Story points anti-bothering table:
Task size Effort Story points
XS 1-2 days 1
S 2-5 days 2
M 1-2 weeks 3
L 2-4 weeks 5
XL 4-8 weeks 8
XXL >8 weeks 13
So I don't have to bother with that fck story points during scrum planning any longer.