In our team, there is a significant difference between zero point stories and question marks. Zero means a story that is so trivial that it is almost free. We try to keep our estimates in the Fibonnaci range as well, 1, 2, 3, 5, or 8 for anything we take into a sprint. Larger numbers are epics that we'd want to see broken up before bringing them into a sprint. But sometimes we have distinct "features" that are so small that they'd be maybe .25 in the numbering scheme above. We don't want to bump them all up to 1, because that would throw off our velocity numbers. So in practice, we accumulate the rounding. Maybe the first one gets 1 point, then the next couple get zeroes, then another 1, then a couple more zeroes, to try to even it out.
A question mark, on the other hand, is truly unknown. The way ScrumWorks handles these is it won't let you take an unestimated backlog item into a sprint, but you can have it on the backlog. Whatever charts show projected completion dates highlight any ranges that include unestimated stories, so you know not to rely on them. In database terms, a question mark is a null, not an integer zero.
My preference would be for question marks to be handled as nulls, but if they are going to be treated internally as an integer, then I would like for it to be configurable. Since I need zero to be a valid estimated size, I'd probably opt to translate questions marks to 999.
