One of the first things used to describe story points is a negative: story points do not equal time. 1 story point can not be equated with 1 hour, 3 hours, or any other unit of time. While it can be advantageous to have a unit of work that isn’t associated with time, it is important to note that story points will ultimately be a unit of time.
Story points are used in conjunction with sprints. The number of story points completed in a sprint is the sprint velocity. But a sprint is a unit of time. It doesn’t matter if that unit is 1 week or 1 month, it is still a unit of time. To say that we can have a sprint velocity that uses story points, but that story points aren’t related to time, would break the transitive property. It makes no logical sense.
Yet, it is still important to treat story points as if they don’t equal hours. There are a number of reasons for this.
For the first, I’ll ask the question: What would you think of first if I told you to think of an animal without thinking of elephants?
Probably elephants!
So what would a developer think if you asked them to calculate the amount of work required by a task, but to not worry about finishing it by the end of a sprint or a release date?
They would worry about finishing it in time!
Software projects are often on tight timetables. There is pressure to deliver quickly. However, it is important to understand all options available, even the time consuming ones, when planning out a project. Knowing about these options can create discussions about how important certain things are. Knowing that the most preferable option for a task that is more important than other tasks will open up conversations about other tasks getting cut.
If you were worried about finishing something on time though, would you try to think of things that would exacerbate that worry?
Probably not! That would be crazy. We didn’t evolve with such terrible survival instincts.
Worrying about finishing a task on time can limit a developer’s ability (or willingness) to bring up more time consuming options. Story points abstract units of time to help prevent people from worrying about finishing a task in a period of time. With that worry gone, the conversation is focused solely on the complexity of a task and the options available.
There are some other advantages as well. Not all developers work at the same speed on the same tasks. Even when you ignore the differences between junior and senior developers, most developers go into some kind of specialty. There’s front end, back end, AI, 2d graphics, 3d graphics, etc. Then there are the different sub-systems at any sizeable company. It is unlikely that all developers have equal experience and familiarity with all of those sub-systems.
The hours required for one task may take Developer A 2 hours and Developer B 4 hours. The hours required for another task could result in 4 hours for Developer A and 2 hours for Developer B. Story points help normalize the estimate of a task by creating a consistent metric for a task independent of the person working on it.
I’m not of the opinion that story points are right for every team. However, it is important to understand the nature of story points in order to use them properly and whether they are even appropriate for a given team. Teams that suffer from the problems story points tackle can benefit greatly from using them. Teams should not use story points just because they read that they should.
Top comments (6)
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.
There's a really excellent discussion of story points, time, and why it's hazardous (at best) to center a team's KPIs around velocity on Ep. 15 of the Tech Done Right Podcast.
In a nutshell: Velocity alone doesn't tell you anything about the health of the team. And if you have enough other information to understand why you have the velocity you do, then velocity is actually less useful than those other metrics.
However a team measures velocity, it's vitally important that we also have other, complementary metrics to establish the health of the code and the team. Sarah Mei has been tweeting some excellent stuff about this stuff. I love her note on the goals of testing as an example of the trade-offs of how to center our daily practice around the team's core values.