I've always loved Joel Spolsky's common sense approach to the software development lifecycle, and his latest article on evidence based scheduling is no exception. It has a realistic approach to quantifying unpredictable elements of team development such as interruptions, meetings and the odd rebuild of your development environment. Estimating is always a big problem, and most developers (including myself) are usually quite optimistic about how long it will take for them to write a particular piece of code. This leads to an un-ending conflict between managers who want to know when something will be delivered, or how much a feature will cost to create. I think Joel offers a real practical approach to this dilema, and I am now trying to think of ways to integrate some of these ideas into a TFS project template.
The only thing i don't think Joel covered is how to go about predicting for the very first iteration, the very first time you start using EBS. I think that you probably need to pick a number or range of numbers to seed your velocity history. You probably need to be a bit pessimistic to begin with, but by the next iteration you'll have some better numbers to work with.