Skip to content

7. Techniques

7.16 Spikes

Agile Extension to the BABOK® Guide

Spikes are used to time-box research, design, exploration, investigation, or prototyping activities in order to understand the effort required to deliver a backlog item or an initiative.

When a backlog item or initiative that cannot be estimated is identified, business analysis practitioners use Spikes to gain the knowledge necessary to estimate what is required to deliver the backlog item or initiative.

Spikes are time-boxed activities that have clear objectives and desired outcomes. Spikes are exploratory in nature and do not produce a potentially shippable product. This includes exploring different potential approaches to a problem including researching different interfaces or tool options.

Spikes are often technical, and may be done to prototype a solution approach to the feature. This technique allows delivery teams to learn how to deliver a working product effectively and efficiently.

.1 Spike Goal

Each spike has a defined goal or outcome in order to define when the purpose has been completed. Business analysis practitioners define a specific time-box to devote to this spike within an iteration.

.2 Type of Spike

There are three types of Spikes:

  • Functional: analyzes a story and determines how to break it down into smaller stories or tasks, or identify where the risk and complexity exists.

  • Technical: determines feasibility or impact of a story or task to understand the technical design necessary.

  • Exploratory: explores organizational risks or impacts for a particular initiative or backlog item.

.1 Strengths

  • Specific activities and time-box provides focus for the team to get clarity.

  • Gives permission to spend time on value-driven research.

  • When used early in team formation, can help team members build and share knowledge about each other and the technology to be used for the solution.

.2 Limitations

  • Can be too long a time-box or too large an item to have clear objectives and outcome.

  • The term can be incorrectly used to reference follow-up conversations.

  • If used too frequently, this indicates the product backlog refinement is not meeting team needs.