Estimating What's Remaining to Finish

 

Pawel caught me being ambiguous. See his comment, “1. I’ve seen features/fixes which required 2 days to be developed and released.”

Sorry, me too. But what I tried to say was this: A feature was estimated to be some duration of person-hours. Those person-hours have come and gone. The feature still requires another 10-12 person-hours, according to the developer. In that case, I don’t trust the estimate of 10-12 person-hours left. In my experience, the reasons for the delay generally have not been addressed. If interruptions caused the delay, more interruptions could still happen. If the delay was caused by having to change the architecture, that could happen again (and I suspect it’s likely). In my experience, until the feature is done, it’s quite difficult to predict when it will be done, which is why I like to start a new iteration to make sure it gets done.

I tried to imagine what would convince me that an updated estimate was more accurate. In the past I’ve only had one thing that would convince me: I would have to see visible progress of more work complete (more pieces of the feature complete) to agree that the estimate of what’s remaining to finish is correct. I’m trying to think of more things, and can’t right now.

Labels: estimation, iteration, timebox

2 Replies to “Estimating What's Remaining to Finish”

  1. I base my confidence to someone’s estimates on past experience. The same like you I generally don’t trust to estimates made by a developer I work with for the first time. But I do take them as good (for different reasons than having good schedule of course). Every time I work with the developer later I judge his estimates basing on his earlier accuracy.
    When I look on my current team I have:
    * two persons who say they need more time than they’ll use
    * another small group who are quite accurate (and I trust their estimates)
    * those who underestimate but I can try to adjust their schedules basing on past experience
    * those who are so abiguous that I rather set some time by myself than rely upon what I hear from them
    When you know who is who it’s easier to make a schedule which can be trusted.
    And yes, in your situation (as far as I understand it) you hadn’t that kind of knowledge. But still, I wouldn’t be so fast with definitive answers like yours and some of those who posted comments. Not enough data for me.
    PS. Merry Christmas and Happy New Year

  2. What about a statement as to what caused the delay, and what’s been done to mitigate it?
    I.e. I was being interrupted all the time, so I’ve moved to an undisclosed location and turned off my cell phone for the next two days. Please forward my mail through the Developer Protection Program.

Leave a Reply