[devjab]

I really like this article. I think impressive how informative it manages to be in such a short space, and how the visual work helps tell the story. I’m definitely going to use this (with full credits) from time to time when the discussions on how a team needs to work with estimations.

What I wish it also included was the not-so-academic parts of estimations. Like how we’re often operating in systems where it is much better to over than underestimate, because it’s much better to never let a client know that you didn’t actually spend that X time compared to letting them know that you need X more. Or how estimating things you’ve done before can also be hard because people don’t actually deliver Y “story points” every week, because sometimes their children get sick, they sleep poorly, whatever. Or how even the most senior developer can spent 3 hours on something silly.

But I guess a lot of that plays into a different sort of discussion. One where we talk about whether a lot of the “control” parts of the work process are actually necessary or just wasted resources. And I don’t want to sound like I think it’s wasted resources, because it can be both and often it’s a combination. Personally I tend to avoid working in areas with too much “control”, if you estimate by anything less than a day, then I’d like not want to work for you. Not because I can’t do it, but because I hate spending time on things that aren’t “the work”. I’m not sure how to include that sort of metric into the discussion, but I think it may be relevant. Because I doubt I’m the only one, and while completely anecdotal, I wouldn’t want to invest in any of the places I wouldn’t want to work because they tend not to do so hot in the long term. So maybe looking at overhead is important? But my sample size is way too small to mean much.