Posted on August 28, 2015
by Doug Klugh

Planning an Agile project can be rather simple when all is known.  When the market is predictable, requirements are clear, the technology is well understood, and the team is experienced in using all of the required tools, there isn’t much research required to complete a project.  But for those times when all of the stars are not aligned and (God forbid) there is something the team does not fully understand, the team will need to dedicate some time to investigation or experimentation in order to complete the project.  In terms of Agile and Extreme Programming (XP), this effort is known as a Spike.

What is a Spike?

A spike is a time-boxed period designated to reduce uncertainty by learning enough about a feature, technology, or process to better estimate, develop, or fix an upcoming feature or defect.  It is used to understand how to best implement a requirement or propose a solution to help the customer make sound product decisions.  All artifacts resulting from a spike are to be thrown away; the only thing to be retained is knowledge.  The goal is to spend as little time and effort as possible to reduce risk by learning just enough to proceed in estimating and developing the work product.  You should not be spending enough time to build a viable solution, just enough time to run a quick and dirty experiment to answer a question.


The term "Spike" comes from an analogy to rock climbing.  Climbers will often stop to drive spikes into the rock face to secure their ropes.  While this does not move the climbers towards the top of the mountain, it does enable future climbing.

Similarly, a spike in eXtreme Programming does not produce production code, but it does enable future story development.  For this reason, spikes are not assigned story points because they do not directly contribute to the team's velocity.  By itself, a spike does not deliver value to the customer.


Examples of a spike may include root-causing a defect or testing the feasibility of an algorithm or a third party solution.  It may also be used to explore design alternatives for solving difficult problems.  If a spike requires more than minimal time and effort, it should be made visible by creating a story for it in the sprint backlog.  Since a spike does not result in development work, it should not be sized.  While team members usually want to get credit for working on a spike, it does not produce artifacts towards the development of the product.  It is simply a small amount of work to aid the team.  Team velocity should be aggregated from work delivered, not work expended.

Small & Valuable

A spike should be a small effort, with minimal impact on productivity.  Teams should not get in the habit of creating spikes to estimate work products.  Remember, estimates are just that… estimates.  They are not predictions.  In most cases, it is simply not worth a large effort to size a story or defect.  A team’s best guess is usually good enough.  Although if expert knowledge dictates that a defect could be of significant size, complexity, or risk, it may be worth creating a spike to root-cause such a defect if the origin is completely unknown.  Intrinsic knowledge should dictate if a spike is warranted.


Many projects will often require time to investigate solutions to tough problems or to root-cause origins of defects.  It is important to disclose substantial unknowns to stakeholders to facilitate identification of risks.  To enable visibility, a spike should be created as early in the release cycle as possible to help mitigate these risks.  Spikes should receive high priority and scheduled with other user stories in the next sprint.  Apply them sparingly and they will serve you well.
eXtreme Programming scope spike user story

Doug Klugh

Doug is an experienced software development leader, engineer, and craftsman having delivered consumer and enterprise firmware/software solutions servicing more than one billion users through 20+ years of leadership.

Similar Articles

subject Article

Managing Technical Debt

The manner in which technical debt is managed can give a company a competitive advantage when it’s most needed or destroy a well conceived product.  When incurred properly, technical debt can greatly decrease time to market, providing a short-term advantage over the competition.  But if that debt is not paid off quickly, it will slowly, yet surely, erode the quality and the value of your software.

Read More
subject Article

A Dozen Ways to Fail at Scrum

Scrum provides a process framework to help realize the benefits of Agile principles.  The value of Scrum has been demonstrated many times, on numerous projects, throughout various industries.  It is a fairly simple and straightforward set of practices and guidelines that will (usually) result in greater adaptability to change, improved productivity, high quality products, and happier customers.

Read More
subject Article

Agile Is More Than Process

There is more to Agile than estimating stories, collaborating with customers, and showing working software.  Agile is also about technical excellence.  And this is where many Agile teams drop the ball.  All too often, teams focus too much on process and not enough on technical practices.  If the effort, complexity, and risk is too great for your team to extend and maintain their software, they will struggle to deliver functionality to their customers at the end of each iteration.  They will struggle to deliver working software as promised.

Read More