As noted on ChoosingTheFirstTest, it is often a problem to get started - choosing the first thing to work on. So, this is a simple CategoryHowTo on how to kick-start your project.

A preliminary work sheet for "getting started" (please amend and reorder as appropriate)

* ChoosingTheFirstUserStory - Whatever you actually work on as your first thing, it should be part of some 'feature' that's part of your goal product. Getting one feature testable (as in "can be ran and seen") will motivate you in your work on the next feature. Choose the easiest (we're searching for a kick-start here!)
* ChoosingTheFirstClass - Your use case will take at least one class to implement. Choose the "easiest"/"most fun" class - high-level or low-level I think is up to personal preference.
* ChoosingTheFirstTest - Now, start implementing the (tests for the) selected first class.

The idea here is that to get things started ''something'' has to be done - what this something is, is unimportant. The idea is that as soon as something is created it can be extended. Like an UnBrokenWindow, this "kick-start" becomes a motivator for extension. Of course, if this is the start of the entire project, everyone should be up for adding stuff right away. ''But'' - when there's some field of functionality that's been avoided for some time in the project (BrokenWindowFallacy - "no one else dares start on it, so why should I have to") - you might have to go down there and just kick-start it.

Once you have put the flag up that "work on the 'scary parts' has begun" - the resistance towards doing other stuff in the same area lessens.