There are situations in which the developers simply don’t know enough about a Story to be able to provide an estimate. In that case, they would perform what’s known as a Spike. The Spike is simply a quick, throwaway proof of concept to allow the developers to gain an insight into what’s really required to implement a story. The result is that the developers can then provide a proper estimate for the story. Note, though that a spike should be limited to no more than a week in duration, and ideally just a day or two.
This is real-world example where a spike was used when the developers didn’t have enough knowledge to make an estimate:
The mainframe system has been in existence for many years, and the Customer and management wish to leverage the all of the work that went into building the tax calculations (and no one wants to attempt to rewrite those calculations!). The mainframe system is a typical COBOL application, while the new application is web-based.
The problem is that the developers have no idea how or even if they can get the information from the mainframe system. There was an attempt by another team using one method, but it proved to be error-prone and not scalable.
So, rather than attempt to give an unreliable estimate on the story, the team decides to take a day or two to do some experiments to determine if it is indeed feasible to get the tx information directly, and if so to try a couple of different approaches.
In the end, there was a reasonably simple method to communicate with the mainframe system via CICS. By the end of the first day the developers were able to connect to and retrieve the information from the mainframe.
Then, the team did a very important thing. They threw away the code used to test the concept, and provided the Product Owner with a reliable estimate for the time it would take to build the actual feature. This included all of the requisite testing effort.