How do "spikes" figure in the schedule / estimation game?

Might be subjective and/or discussion.. but here goes.

I've been asked to estimate a feature for the next big thing at work. I break it down.. use story points come up with a estimate. The feature however calls for interfacing with GoDiagrams a third party diagramming component in addition to various other company initiatives.. (a whole set of 2008_Limited_Edition frameworks/services:). I've been tracking myself using a burn-up chart and I find that I'm unable to sustain my pace primarily due to "spikes".. Definition

I estimate for 2 points a week and then I find myself working weekends (well trying to.. end up neither here nor there) because I can't figure out where to hook in so that I can preview user-actions, show a context menu, etc. In the end I spend time making spikes that throw my schedule off-track... and decreases its value.. doesn't give the right picture.

Spikes are needed to drive nails through the planks of ignorance. But how are they factored into the estimation equation? Doing all required spikes before the feature seems wrong.. (might turn out to be YAGNI) Doing it in between disrupts my flow. Right now it's during pre-iteration planning.. but this is pushing the touchline out on a weekly basis.

Solution

I guess you are constantly underestimating

what you do already know about the 3rd party component
how long it takes you to create usable/helpful spikes for unknown areas

1. Get better at estimating those two things.

So, it's all about experience. No matter what methodology you use, they will help you to use your experience better, not replace it.

2. Try not to get lose track when working on those spikes.

They should be short, time boxed sessions. They are not about playing around with all the possible features listed on the marketing slides. Give them focus, two or three options to explore. Expect them to deliver one concrete result.

Update(Gishu): To summarize

Spikes need to be explicit tasks defined in the iteration planning step.
If spikes exceed the timebox period, stop working on it. Shelve the associated task. Complete the other tasks in the current iteration bucket. Return to the shelved task or add a more elaborate/broken down spike to the next iteration along with the associated task. Tag a more conservative estimate to the generation 1 spike the next time.