Estimates are a fact of life for most of us. And often – while not always – they are a necessity. If I weren’t using some form of estimation on my current projects, they would be twisted up like Sherman bow ties. And on fire.
This brings us to an apparent paradox. The larger and more novel something is, the more we need to put some estimates around it – lest it end up a railroad-side barbecue. Yet the larger and more novel something is, the tougher it is to devise meaningful estimates.
But this isn’t a real paradox. It’s just a starting point.
At the very inception of a project or product we don’t need a thorough estimate of everything. We just need a simple set of estimates that tell us what to label the tick marks on our deliverable-level cost graph. Were we to cost out our initial estimates, would we be measuring project deliverable in increments of one thousand dollars, or ten thousand, or a hundred thousand? This lets the organization and team know what league they are playing in and how much to invest in upfront estimation and project tracking.
Most things we need to do should not be difficult to estimate. Anyone who’s been around the organization long enough should know how long it takes to spin up a shared development environment, the average time to build out a screen, and the usual duration of system and acceptance testing. For the rest we use development spikes.
We use a development spike to tell us whether some technical activity is feasible and/or to tell us how long it could take to complete.
- Can we implement two-way SMS in our current infrastructure?
- Can we reduce costs and time by using an open source charting package (or is it better to roll our own)?
- How difficult will it be to upgrade to Ruby on Rails 3?
- Can we do multiple file uploads without flash?
- Will it handle the load?
- How do we make these two systems talk to one another?
A spike is typically throw-away code. It’s only purpose (at least in this case) Is to give us enough knowledge to state a fuzzy estimate with confidence.