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.
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.
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.