[veidr]

In my own experience as a software developer, it is incontrovertibly true that the smaller the unit I/we use to break things down, the more accurate the resultant time estimate becomes.

However, as padobson notes, there's an overhead associated with breaking complex things down into smaller units. There's a point at which it becomes counterproductive.

I feel like I have, over the years, sometimes crossed that line.

(And, other times, not gotten close enough to that line and been surprised by weeks/months of schedule disintegration.)

[analog31]

I wonder if this is because one never rounds down to zero, so that finer grained estimates automatically pad themselves. I've noticed that estimates run higher and higher, the longer the planning meeting lasts.

[scarface74]

I was over a project and part of releasing the next feature, I decided that it was best to tackle some technical debt based on my now knowing a better way than I did when I first implemented the system - basically bringing it up to our current standards that involved a lot more automation and other features that would make my life easier.

I wrote down in detail all of the tasks involved just to help me estimate like I always did. By this time we were transitioning company wide to scrum.

Every task I put in was scrutinized by the contract “scrum master” as it wasn’t part of the MVP even though I knew it wouldn’t affect the schedule since I had prior work I could base it on.

The rest of the dev team had the same issue. I got tired of fighting and the scrum master was getting in our way. I told them to do what they thought was right and run it by me first if it was anything major. None of the things we were trying to do were customer facing, they were all backend architectural things.

I tried to fight the good fight but then had the epiphany - I didn’t have to. I’m the dev lead, I do the code reviews and no one higher than me will be looking at the code. I told them not to be detailed in the how within our project tracking system.

[wil421]

Really love your comment as it strikes home. Just transitioned to scrum last year and have a terrible PM I mean Scrum Master. No help at all just and he only makes sure Scrum meetings happen. Also he’s way overconered about velocity and story points.

Another senior dev told me the same advice you realized. Now we just create more generic stories. He’s stared to go story by story and wants to know how it meets a business objective.

Our stuff is extremely customer facing and time critical. I welcomed Scrum over Agile but a bad Scrum Master can kill the benefits.

[Retric]

Smaller tasks have less accurate estimates. If you say something takes 1h and it actually takes two days that's ~16x as long or a week long task taking 4 months. All it takes as a small corner case or odd bug that you did not consider and suddenly your estimates are worthless.

The only thing that makes small estimates seem better is the worst case tends to be less time, but overall they don't help.

[shagie]

An estimate is not a single number. Rather, an estimate says “it may take 1h if everything goes well, it may take 16h if things go bad.” This is then followed up with “at 1h, I’ll update with either a done or a revised estimate.”

Giving single numbers for an estimate with uncertainty is bad for all parties.

Additionally, with experience one can get better at giving estimates with less uncertainty for well known tasks and recognize the uncertainty for other tasks.

[Retric]

That's not relevant. Low / high estimates can be written in this form: X hours +/- Y%. 1-3 days seems wide but it's just 2 +/- 50%. 1 hour or 2 days ~= 1 day 1 hour +/- 90%.

AKA Y is much higher when you deal with low hour estimates.

This is most noticeable when you have lot's of tasks. If you think 200 tiny tasks may take 1 month or just over 1 year that's an almost useless estimate.