"POINTS AREN'T TIME! THEY'RE EFFORT AND/OR COMPLEXITY!" I've been routinely told. Yet... low complexity stuff was expected to take less time, even if it was high effort. All 'in my experience' of course.

Changing 95 files because someone didn't want to centralize some value in a method call last year (YAGNI!) is now high effort, even if low complexity.

Then... "that's too many files in a PR! break it up! no one can review that many files!" It's the same two line change in each file - this shouldn't take that long to 'review'.

I've often spent more time arguing about points/effort/estimates than doing the low effort work. But if we don't record it properly, you won't get 'credit' for the work!

Slow-paced insanity when taken anywhere near close to its logical conclusions.

I love hearing "points aren't time but you can think of them like days"

My response to estimating is that if you want anything accurate I’ll need time to estimate - roughly 1/4 of the estimated work should be spent estimating.

As a rule of thumb, if the work is estimated to be a day then is should take me 1/4 day to estimate. If two days then half a day to estimate. If 4 weeks then 1 week to estimate.

We normally continue with guesses that are meaningless.

What would you do if they actually gave you a week to come up with an estimate? Start drawing Gantt charts?

1/4 seems reasonable for a day or two, but I dunno… it seems like there must be some constant factor?

I’d draw a lot and probably prototype as well - I suppose the main thing is that we never get to that as we estimate but don’t do “big design upfront”

Haha after 5 years our scrumlord finally relented that 1 point was 8 hours for our team because even he was apparently getting tired of the cognitive dissonance.

Also don't forget story point Goldilocks.

We don't create 1 point stories, you need to roll this up with another story! Hey we don't do 13 point stories, you need to break that one up! 8 points? you sure that isn't a 5? 2 points, 3 points.. what's the difference just mark it as a 2.

OK so basically we just have 2s & 5s then? Amazing.

I had a colleague who told me his secret - "I just say 3 or 5 to anything". That was it. He would pause, then say 3 or 5. Anything I was asked to estimate, I'd give real effort estimates based on their scale. And was always pushed back on like you noted above. And it was a constant struggle. Yet... I always (like... over 95% of the time) hit all my targets, delivered early, and would sometimes pick up the other slack. The other guy with 3/5 - would almost always get pulled in to some other project (or aspect of the project) so almost never got his stuff 'done' (often I would finish it). But on paper... his estimates were always 'so easy' and his tickets always got done (often by me) but I was the 'difficult' one (for many other reasons beyond this).

Ah yes, but remember "we don't measure individual velocity!".

So all that gets remembered is .. this guy always argues in the scrum meetings, AND his estimates are always high, smdh!

If you try to right size tasks, you can just count tasks instead of estimating them. This approach even has a catchy brand name in agile circles: #noestimates.

In every team I’ve tracked, the task count burndown velocity was impressively linear, whether looking at weeks, months, or years of data. I think we can thank the Law of Large Numbers, with shorter than average and longer than average tasks balancing each other over time. (We never bothered with story points, so I can’t compare.)

The problem with Agile induced "right sizing" of tasks is that you artificially split atomic units of work into multiple tickets.

A single deliverable is now 3-5 different tickets that might get split across sprints. It now becomes harder to express when a piece of atomic functionality will be delivered because you need to track with dependencies across the tickets, etc.

So it feels like contortions to make reality fit into Agile which negatively effect reality.

Let's say we are using Agile in the kitchen and we have 3 tickets - 1) research recipe, 2) collect ingredients, 3) bake cake. These are logical and understandable to a stakeholder. You can assign them different story points / sizes / durations / whatever. It's relatively easy to express the dependency and also keep it in your mental model. Each has a deliverable - 1) recipe & ingredient list 2) the ingredients 3) the cake.

However Big Agile Coach argues that really it should be 1a) research recipe, 1b) collate ingredients required, 2a) research pricing on ingredients 2b) create per-vendor ingredient lists 2c1) buy ingredients at vendor 1, 2c2) buy ingredients at vendor 2, 3a) clean kitchen 3b) prepare cake batter 3c) bake cake 3d) cake frosting/finishing

OK which of these 9 tickets depend on which / which can be parallelized / which are best to keep with a single dev, which should be done within a single sprint vs split across? Etc.

> "POINTS AREN'T TIME! THEY'RE EFFORT AND/OR COMPLEXITY!" I've been routinely told. Yet... low complexity stuff was expected to take less time, even if it was high effort. All 'in my experience' of course.

This realy grinds my gears. I had a recent experience with a scrum master (technically a delivery lead but in practice a scrum master). Really nice guy, smart, easy going. We had many discussions about the value of estimates, and the whole "it's complexity, not time" trope would come up. So I asked what the estimates were used for. Turns out they're used to forecast cadence / velocity. Of course, knowing that we were going to be asked why a small story was taking two weeks to complete, we'd start sizing based on time. After all, we're humans, biased and flawed.

Now you tell me, how do you want a measure of complexity to be a predictor for cadence when these 2 things are at best orthogonal?

I saw this on my last job!

I was already adding time to my work like an extra point or two here and there

But then in the grooming session the whole team would guesstimate even more story points! I was dumbfounded! This was beyond all of my levels of tolerance and rationality but it kept happening every sprint until something that was a 0.5 for me was a 5 point and I would have two 5 point tickets for the whole sprint that I would submit to QA one day before the sprint ended, 9-10 business days later

and actually doing that made me a star performer, what the hell!?

Scrum teams are self-managing, and point values are used for gauging your own team-workload.

When you point a "0.5" and your team points a "5", stop and discuss the discrepancy until an alignment can me found. Keep doing that, every task, until you a collective meaning of "a point" is found.

Personally:

* Less than 1 - These are a smell and should not exist. These misalign incentives and encourage "bike shedding".

* 1 point tasks - no task that requires 2 people (dev and qa) is a 1-pointer, so this is something that needn't be QA'd. 1 point tasks should be rare items that can't be a subtask of a "real" task.

* 3 point tasks - These can be done in a day (depending on the team's opinion, this might be multiple people and still be 3 points). Virtually every task should be a 3.

* 5 point tasks - These are tasks that cannot be broken down to be done in a reasonable amount of time. These are generally things that have minor external dependencies. ("not hard but I'll have to get a server spun up by the unix admins.")

* 8 point tasks - These are rough tasks that haven't been fully dissected by the team and are the scrum version of a "code smell". The team should break these down and dissect them.

* 13 point tasks - "There be dragons here" tasks. Large unknowns and these tasks should not be added to a sprint until they're broken down further.

Meetings are long enough without people spending extra effort doing it right :)

Sharpen the saw, man.

It's a one-time conversation (per new team configuration) that makes every conversation thereafter fast.

My team's pointing sessions are lightning.

Even when you do have a new team member that wants to discuss a "0.5-vs-5" point disparity, you explain the above in less time it took to read it and get back to work.

If you measure velocity then the points are additive, how do you reconcile 3 point tasks doable in a day and 5 point tasks not doable in a reasonable amount of time?

Isn't 5 points less than 2 days then?

For the record, in my team we don't use story points or measure velocity. I just had a frustrating discussion with a peer team that didn't plan an important task because "its 5 points and does not fit into a sprint".

When I've used Story Points as the team manager, one of the things I made sure of was to completely avoid looking at any given team member's velocity, ever. I only cared about the team velocity, and only for the purpose of estimating risk to the timeline.

At the round-table people would report their retired points, and I'd add them to a running tally I kept on a piece of paper next to me. "2+1+0+5+2+2+8+0+1." Then I'd record the velocity for the week for the whole team, and we'd move on.

Smart. Not all contributions can be measured in points. Some team members do a lot of support/mentoring work, for example.

That kind of inflation corrects for itself. Because you're supposed to look at the previous sprints to judge how many points you'll get through this sprint.