Process

Sophie Déziel gives a great summary of her team's approach to research spikes. We handle them in a similar way at Closely but I especially liked her simple framework for documenting the outcome of the work (something that too often gets ignored in the rush for an answer):

The goal of a spike would be to produce knowledge and to reduce uncertainty. So, it’s important to follow some guidelines to make sure that the knowledge is communicated. This can be very useful for every level of development and management. So, here is the questions to be answered (and documented) in the time allocated:

• What is the problem that we want to solve?
• Is it feasible?
• How much effort does it need?

When the conclusion is that it is possible and the amount of effort is defined, the knowledge produced and documented should be enough for the product owner to create the stories to do the real work and help the development team to estimate it.

Some good advice from Mike Cohn on how to approach story decomposition:

When something will take a long time to develop, that's exactly when I want to use a process that forces me to get early and frequent feedback. This will counter many developers’ tendency (including my own) to retreat into a cave thinking we know what our users want.

In my experience, it's always worth digging a little deeper during planning to find ways to split user stories so they can be delivered in a single sprint.