Hacker News new | past | comments | ask | show | jobs | submit login

> Of that, probably the formal estimation methods (replaced in Scrum by intuition for some reason) are the biggest loss.

Curious about that point because for many engineering tasks the variance in the estimates is so big that I wonder whether any formal way of estimation actually works. I did some analyses on the correlation between estimate and actual development time in a project I worked in and the correlation wasn't really there. Sure, there was a difference for the very large work items and the very small one but overall the estimates were fairly useless, especially when it came to anything that touched operations. I just googled formal methods for estimation in order to see what you might mean by that and nothing appeared to be something I'd assume to be more powerful (a priori) due to my lack of confidence in workload estimation overall.

Note, btw. that the Scrum Guide doesn't make any mention of estimation at all, neither prescribes it nor disallows it, just says that the team should plan a sprint (roughly speaking). Even the typical "story point estimation" stuff that people think is attached with Scrum, its more of an XP practice that has been carried over.

Personally I think that Scrum took a weird turn in its lifetime with Sprints becoming shorter and shorter to the point where there can be no meaningful work (with customer benefit / demoable in the sprint review) be completed within a Scrum. Maybe its possible to ship a couple of CRUD-website-features within 2 weeks, but for the B2B software I am working on a feature is too complex for 2 week cycles. And if your tasks are small enough to fit into two week cycles, why aren't you doing Kanban?




> I wonder whether any formal way of estimation actually works

I agree that it is a legitimate concern, I certainly do not advocate a position that software cannot be estimated or planned at all. I think it can be, but only up to certain time granularity, where the attempt to gain understanding for a sensible estimate (and describing what needs to be done) becomes essentially comparable to writing the code in the first place.

I actually have an underdeveloped idea how we could have a completely formal approach to tackle uncertainty in SW development, but it is purely theoretical so far (using a combination of functional programming and information theory).




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: