estimate-free still needs estimation

Some agile teams have moved to a kanban-style process in which there is no explicit planning game or estimation cycle--but I think it is an oversimplification to say there are no estimates in the process. How could a team have dozens of story cards approximately the same size if no one ever tried to predict the size in advance?

I posted the following to the XP list today, in response to the Task Underestimation and Overestimation thread:

To [estimate], or not to [estimate]; that is the question,
Whether 'tis nobler in the mind to suffer the slings and arrows of outrageous [deadlines],
or to [code bravely] against a sea of troubles, and by [overtime, to deliver]...

When I think about it, the experiments I've done to remove estimation from our stories were more about reducing the waste, than entirely removing estimates. Consider this--there must be *some* implicit estimation if we're going to slice our stories until they're all about the same size.

My current team has rejected estimation-free cards. We tend to like the size value on the card to remind us of the scope, to keep an urgency about the work, etc.

Still, we've also been unable to add estimates to all cards, using our current planning game; maybe 1/3 of the cards in an iteration show up without estimates at all, and it's too much BDUF to split the stories more. Instead, we treat an un-estimated story as a timeboxed research or a spike--the only expected result of these kinds of cards is a stack of new story cards with estimates. Sometimes the product owners pick how much time to invest in this research, in which case we'll tag the story cost as SPIKE:2, for example, to mean 2 points' worth of spike activity.