Ultimately, we are bound by time, not complexity. Why does it matter how complex a task is? The product managers and customers wont care how hard we as engineers have to think or reason about a problem; to them, the only thing that matters is time until delivery.
Time until delivery for good managers and customers is a range. Can you estimate getting 10kg of potatoes from grocery store that is 35m driving roundtrip away? Can you say it will be exactly 40mins because you can pick up and pay in 5 mins? I don't, I can say it will take between 40mins and 2h. There are always things like card terminal stops working or you get stuck in traffic because of an accident.
Complexity in that example is uncertainty like I do expect high traffic and there might be an accident happening but if there is less traffic and I hit all green lights 40mins going to be easy.
We all know bad managers and bad customers will expect me to get that bag of potatoes in 37 minutes and then ask 10x why did I not drove over that police officer that was stopping the traffic because of an accident to get their potatoes on time.
I don't follow how we go from "they are bad product managers and customers" to... therefor time estimates are bad. I do not think it is unreasonable for our primary stakeholders to ultimately care about time. I also do not think it is unreasonable to give error bars in estimates like "this project is uncertain, therefor estimates will be variable".
The bad managers are those who ask you for an estimate and then take it as a commitment.
.
"How much time will this take?"
"Not sure; approximately 30 minutes, but could also be 20 or 40 minutes. If we are very lucky then 10 minutes, but if we are very unlucky, maybe an hour or more."
"Spare me the details, I just need one number for the report."
"Uhm, 40 minutes?"
"You just said that it would be approximately 30 minutes, didn't you?"
"Yeah, but I wanted to add some safety margin..."
"If we keep adding large safety margins to everything, then the project will take forever. As you said, some tasks are completed faster, some tasks are completed slower, on average it will cancel out. I need your best estimate."
"Uh, okay, then 30 minutes. On average."
...the next week...
"So, you guys told me this would take 30 minutes, but it actually took 35. I think we need to have a serious talk about your performance."
No, it's still a range, the difference is simply that a good manager would plan such that Christmas is at the very far end of the range. Bad managers will plan with the optimistic end of the range, and then expect crunch time from exploited workers following their passion.
Story points aren't useful outside the team. They're for the team to help it figure out roughly how much stuff it can do each sprint. They shouldn't leak out of the team.
I understand what you're saying - of course in some sense they're convertable. But the point is to not think about time when estimating, because if you estimate time you don't factor in things like other tasks, or holiday, or anything else. Or if you do you have to spend ages trying to account perfectly for time.
Instead, if you estimate complexity (e.g. I think this task is a 3, just as a starting point, then this task is roughly the same, so it's also a 3, then this one is similar but will take almost as much testing due to its difficulty, so we'll call it a 5, then this one is very simple, not even half as difficult as the first one, so it's a 1, etc), then try and keep that up for a few sprints, then figure out how many points fit into a sprint, you automatically factor in other factors (like "I have to log into Okta ten times a day", or "people keep getting pulled into meetings") through practical observation of what got done, and you get better at predicting what you'll be able to achieve in a sprint.
It's not perfect; it just removes the need for certain entire jobs devoted to accounting for time, which you can spend on another developer instead, while also being a reasonable measure of what you'll get done, and only takes about an hour every two weeks.
If the problem is "we're not accounting for holidays in our time estimates", I can't see how the solution could possibly be "time is obviously a flawed measure, so we'll use this other measure which has this hazy relationship with time, but we all agree that it's definitely not time, although we have trouble saying what it is"
personally, I find it much easier to say 'normally, I would get this to you by wednesday of next week, but we have that offsite and my wife's parents are visiting, so does friday work for you?'. than 'this is a 3', so, I guess this fits in this sprint?
changing units and names of things really seems like a deliberate attempt to rob the discussion of any actual meaning. just a comfortable empty formalism that masks the fact that we aren't trying to come to grips with the most difficult parts of our job
But you don't estimate holidays in ... you estimate how long it would take if someone picks on the task Monday morning and works on it full time.
If someone picks up task on Monday then has 20 other meetings - estimation is still the same, he just continues after those 20 meetings and you just don't care when estimating.
Only thing is if at the end of sprint dude is saying "I started X then I had 20 meetings so I did not make it" - well you just accept that or you don't put guy into 20 meetings.
Functionally you're just created extra steps and confusion by not calling it a time estimate, or at least something equivalent to time. Even with a real time estimate you shouldn't be planning by going "well you work 80 hours this sprint, so we plan 80 hours" - you should be doing the same consideration of looking at how many "hours" were completed in the last few sprints and plan based on that number. If we're in agreement that these numbers are for the team only then it shouldn't matter if they consistently under or over estimate the hours, nobody outside the team should know or care how many "hours" they complete in a sprint.
The confusion part is that by calling it "complexity" and saying it's not a time estimate you've muddied the waters on what it is, people will debate the definition and intentionally differentiate it from actual time. I've seen this before, the points-per-sprint never stabilizes because teams have cards where "that's a 1 point card because it's simple, but it will probably take a week". And then suddenly they're ignoring the points during planning to instead come up with an actual time estimates (which also don't work because they don't track those against multiple sprints).
I think time variability increases with the level of complexity. In this context I see the idea of task complexity being related to uncertainty in the time estimate. This makes it fit nicely with the Fibonacci sequence.
Time variability also increases with the time estimate for a task. If a task is "about two weeks", then it might be 1.5 weeks or it might be 4 weeks.
But if a task is about 1 day, it may take 4 hours or 4 days, but it will almost certainly not be 1 month.
Points are always just a proxy for time, and work the same way. Not matter what anyone claims, as long as you use points to plan time-abound sprints, points are directly a measure of time.
Yes, project managers easily can have that level of comprehension, but it is rare to meet a project manager that understands that a time range is something like a confidence interval. That is, if it is estimated a task will take 3-9 weeks, with some probability (say like 10%) it will take an even shorter or longer amount of time. There is uncertainty encoded in the time range, but the time range itself is also uncertain.
Fundamentally, the problem is that project managers set deadlines based on statistical estimates from developers. Despite the fact that they set the deadline and do not understand the dispersion, they want developers to be responsible for misses. Sometimes, people mistankenly believe that there
is some magical practice that can eliminate the uncertainty from estimation. You can make predictions with things like story points and achieve a certain amount of accuracy with a certain amount of dispersion. Statistically, it is the longitudinal behavior that can be predicted (sprint success rate at a specific velocity on a stable team), but we focus on cross sectional details (we missed this sprint).
Project management is generally not considered a field requiring statistical expertise but modeling reality of the work requires it.
No, points mash together size and uncertainty. A task that's "3-9 days" will have fewer points than a task that's "3-9 weeks". And a real that's "3 months give or take a week" will have more points than either.
Of course, there's actually no such thing as a "3 months give or take a week" estimate for a task. It's basically impossible in programming to have a task that takes that long with that low a level of uncertainty. So in reality, time estimates have the same properties as points: the higher a time estimate, the more uncertainty it represents.
