Why Artisan Agility Recommends Against Sizing a Backlog Item Defined as a Spike

Introduction

In Scrum, a “spike” is a commonly used reference to a product backlog item that serves a specific purpose: research, exploration, or investigation. Unlike other backlog items that deliver tangible functionality, spikes are designed to gather knowledge or resolve uncertainties. At Artisan Agility, we recommend against assigning a size (e.g., story points) to spikes, and here’s why.

1. Nature of Spikes

• Unpredictability: The primary purpose of a spike is to explore unknowns, which inherently makes it difficult to predict the amount of work involved. The very nature of a spike is to answer questions or resolve ambiguities, meaning that the scope and effort are often undefined at the outset.
• Outcome-Based: Spikes focus on outcomes, such as gaining knowledge or clarifying a technical approach, rather than delivering a specific feature. The value of a spike lies in its results, not the effort expended.

2. Sizing Conflicts with Spike Objectives

• Contradictory Goals: Assigning a size to a spike can create a conflict between the need to complete the research and the perceived effort involved. If a spike is sized, there may be pressure to complete the investigation within that estimated effort, which can compromise the quality of the research or lead to incomplete results.
• Encourages Misuse: Sizing spikes might encourage teams to misclassify other work as spikes to avoid committing to a size or to artificially inflate their velocity. This can lead to inaccurate sprint planning and a distortion of the team’s actual capacity.

3. Impact on Velocity and Estimation

• Distortion of Velocity: Including the size of a spike in velocity calculations can distort the team’s velocity metrics. Since spikes do not deliver functionality, including them in velocity gives a misleading representation of the team’s ability to deliver value.
• Skewed Estimates: When spikes are sized, their unpredictable nature can lead to either underestimation or overestimation, skewing future estimates and impacting the accuracy of planning and forecasting.

4. Best Practice: Timeboxing Spikes

• Timeboxing Over Sizing: Instead of sizing spikes, Sierra Agility recommends timeboxing them. A timebox defines a fixed period during which the research or exploration should occur. If the spike’s objectives are not achieved within the timebox, the team can decide whether to extend the research, pivot in another direction, or take an alternative approach.
• Clear Deliverables: With timeboxing, the team sets clear expectations for what should be achieved by the end of the spike. This approach ensures that the spike serves its purpose without unnecessarily inflating the backlog or distorting velocity.

5. Conclusion

Spikes are a valuable tool in Agile workflows for reducing uncertainty and enabling informed decision-making. However, their intrinsic nature makes them unsuitable for traditional sizing methods used for other backlog items. By avoiding sizing and instead employing timeboxing, Sierra Agility ensures that spikes contribute to the team’s understanding without compromising the integrity of sprint planning, estimation, or velocity tracking.

This approach aligns with Sierra Agility’s core principles, promoting accurate, efficient, and value-driven Agile practices.