Quickie: Poor Estimation Is Not Your Problem
I encounter many senior and middle managers who believe that their software teams are poor at estimating, and seek to improve estimation accuracy and etc.
In most cases, the problem is NOT poor estimation skills or techniques. Rather, the problem is poor due-date performance (how often things are delivered on time).
As the world of #NoEstimates shows, delivering on time has little to do with estimation competence.
If you’d like to discuss some things you CAN do to improve due date performance (delivering on time more reliably) please do get in touch.
Think Different
What is a “due date”? And what made it important?
Isn’t a “due date” just another estimate? If someone has identified some clear body of work (a number of detailed, defined tasks), with an expectation that they all should be completed (possibly also with some expectation of quality, and visible results) by some date, haven’t they just *ESTIMATED* that that body of work can and should be completed in that period of time by those resources?
In my experience, most “due dates” are arbitrary. They are literally nothing more than estimates.
Maybe what we should be focusing on is business value and capabilities.
Like, “After some investment, are we now able to sell and support product ?” (… that we were *not* able to, before that time)