Welcome to Episode 2! I decided I better start numbering my YouTubes, so I went back and added numbers to the previous two (including the 2 min Welcome video which seemed appropriate, and computer sciency, to be numbered at 0 – Ric Hehner would be proud).
This is building on the previous video where I went over a rough-an-ready “Horizon Plan” and used units that I called “Days” without going into any detail. Here I clarify what I mean by “Days” = Effective Coder Days, or ECDs.
I start out by saying if you can’t measure it, you can’t estimate it, so for everything I estimate there has to be an operational definition of the the thing based on how you would measure it after the fact. I use height, weight, and strength as illustrations.
I go on to talk about how to “measure” the size of software. I discuss and discard both lines-of-code and function point analysis. I say the only reasonable approach is a time-based estimate, but that “confounds” four things:
- The “inherent size” of the work item (whatever that means).
- Who is working on it.
- How productive that person will be working on that thing with the time they dedicate to it.
- How many hours of dedicated time they can put in over a period.
I say that last thing is quite easy to strip out and measure separately. I introduce the concept of workdays and work factor to convert workdays into ECDs. I explain why I’m only sizing coder time, working alone, and only up to the point the dev thinks they are done, preferring ratios for the rest.
I then go on to discuss how estimates and stochastic distributions intersect. I eventually discard anything like that as being impractical to implement (but useful to bear in mind). And ultimately not needed, as we eventually converge on a very tight distribution as we get closer and closer to the end, assuming we have good information flow.
I then take some time to heartily disparage “abstract story points”, or “agile story points”, or just “story points”. Man, do I hate those things with a passion!
Enjoy the vid!
Jeremy Chan says
Found this quite accurate, and humourous. The “asking 3 times” is a great technique, I find. Here’s an experiment I ran with staff at one point: https://www.linkedin.com/pulse/trouble-software-estimation-jeremy-chan/
David Penny says
I hadn’t seen that article before. Great work!