Hacker News Reader

Comment by wsc981 | Hacker News Reader

Just estimate time. In the end, whenever I worked with story points in various companies, even though developers, Project Managers or Scrum Masters would often state that Story Points are a measure of complexity, in the end, the Velocity for a given sprint was measured in Story Points as well. So, in the end a Story Point is equal to an amount of time in a sprint.

This is also stated in the article:

> Story points do not represent Time, yet the Velocity metric they are usually combined with defacto converts them to time, sabotaging everyone from the start by doing the thing that you can't do with a precise number and a range...adding them together.

Better yet, just don't bother with SCRUM and all it's pointless and time-consuming ceremonies and just get shit done. This is my preferred mode of working and I've been lucky to be able to work like this for the last couple of years.

View on HN

I disagree with the first part. The only thing less useful than estimating points is estimating hours.

If story points convert to "hours"/"days"/"time" in the end of the day, why is estimating in time less useful?

Asked in another way - why is it more useful to estimate in an unit that's more abstract/distant-from-reality?

I mean I agree, but it's because you should estimating in days.

No task significant enough to warrant a ticket in a queue and design effort takes less then a day. Even if you you swear it's "done", the more likely outcome is you'll be dealing with it for hours later that week when some sort of an issue crops up.

I've seen so many people "bid" 0.5 and 0.25 day units of time (in points or whatever) and then act offended when I challenge them on that, yet 3-4 days later they're still plugging away at the same task due to "complications".

Yep, I've been guilty of this in the past. Any estimate shorter than a day is for a task that wasn't worth the time to break it down and estimate it as a single unit. Like "modify firewall rules to allow traffic to port 1234" -- no, that's not a separate task, that's part of whatever task requires you to do that to get the whole thing to work.

And any task that is meaty enough to be a task will take at least a day, and probably longer.

The one place where I will more or less disagree is when bug-fixing. There are always some bugs where you pop open the debugger and have it solved in an hour or two. I've been at places where bug report tickets were handled differently from stories/tasks, though, so maybe this is fine to just think about separately.

The real question is “how to get shit done”?

Scrum, agile, safe, etc.. are ways to get shit done that all target the measurement.

Estimations are that measurement.

The nugget from this article that seems to missed by many is the subtle but strong advocacy for XP style Mob/Pair programming.

Say no to SAFe. It's a middle-management orgy of mediocrity.

I believe this latter suggestion is known as the “programming, motherfucker” methodology [0]

[0] https://programming-motherfucker.com/

Reply on news.ycombinator.com