There must be a better way to package the no-estimates message, and it's not this.
There must be a better way to package the no-estimates message, and it's not this.
Saying no estimates is akin to saying "this is hard, we suck at it so we quit." The problem isn't solved, you still have no way of measuring how complete you are and when you'll be able to turn new things on.
We use a combination of story points and historical reference where we can during our estimating phase. So if we are talking about adding a new feature and wet estimate it out we go look at the actuals from a similar change that we did before to see how is base we might be. We also like story points because they are a ballpark and help us judge if we are estimating reasonably well. If we are continually having things signed low points that take data to finish, we can address that. Fast feedback and lots of iterations. The thing teams fail to do is to measure properly. If you measure too much no one fills out their stuff accurately and then you've just got garbage. Measure the wrong things and you're blind. Measure nothing (no estimates) and you're just giving yo.
We don't try to measure to the minute or hour. Things are basically 'quick' 1hr or less, 2hrs, 1/2 day, 1 day, or a 1/2 week for a task we know is big and hairy that has a lot of sub tasks that we don't really want to dive into the minutiae of it because what's relevant is that X does A and B, not that X requires T, U, and V to be done first.
That's the hard part for us, enough detail that its meaningful without spending all your time planning to plan.
Indeed, most projects are remarkably (and sadly) similar to other projects we've done before.
ReRe's Law of Repetition and Redundancy [1]
A programmer can accurately estimate the schedule only for the repeated and the redundant. Yet,
A programmer's job is to automate the repeated and the redundant. Thus,
A programmer delivering to an estimated or predictable schedule is...
Not doing their job (or is redundant).