My Favorite Analysis Artifact: Code

On projects where you're integrating with legacy or vendor systems, it's often necessary to dedicate developers to technical analysis of the system before stories can be broken up reasonably and estimated by the team. Typically the output from that analysis is technical notes on a wiki page (or Mingle card). Those notes are helpful, but keep an eye out for the opportunity to do something far more useful: automated specs showing how to get the system to do what you need (or something close, if the details haven't been worked out).

Since your specs are self-verifying, whoever picks up the story will know for sure that the system works the way the specs say, which is never the case for notes on a wiki.

Code is a natural and unambiguous way to describe using a system, so it eliminates challenges of interpreting someone else's notes. It's also likely faster for developers to write code than to write prose.

Resist the temptation to go beyond the spec and write production implementation code. If your requirements haven't been fully baked, you'll just be bloating the codebase. Your specs can be clearly labeled as analysis artifacts, and once the real integration has happened, they can be deleted.

I'd recommend using this approach any time you already have a test environment for the legacy database or application. Besides giving you more manageable and useful analysis artifacts, it's likely to keep the developers assigned to do technical analysis much happier.