This has probably been said before, but it's extremely important: Evolutionary development is all about coding what you know at the time you've picked the story card off the wall. More often than not, the harder you think about what the "proper" design might be for the solution, the further away from the target you'll actually be. When presented with a problem, don't stop and think about what might be the most elegant way to design the solution - Just Code It!
Presumably, if you're picking the story off of the wall, some time has been spent mulling over what the story means for the system under development with the necessary stakeholders. You should also have a pretty good idea of the existing pieces of the system that will be affected, as you've considered this when giving your point estimate. So, start coding for the functionality that you think you need.
As you write tests, and build functionality to make them pass, you'll probably run into pieces of the system that somehow don't jive with the new functionality that you're developing. Stop development of the new feature. Comment out the currently-failing test that you're trying to get passing. Start refactoring the existing code to make sense in light of the new requirements, but only as they concern your currently-failing test! Don't stop until you've got the existing system singing the sweet song of cohesion. Then, uncomment out the currently-failing test and make that baby pass!
The important thing to keep in mind when coding like this is that you should never consciously degrade the quality of the existing system in the name of making the new functionality "just work". Each time you finish a story, the system under development should be a cleaner, more complete facilitator of client value, and no more difficult to further-extend and enhance than it was when you started working on the card.