Difference between Spike and Enablers

Last post 11:51 am August 16, 2019
by Thomas Owens
7 replies
Author
Messages
12:15 am August 15, 2019

There are so many Google definition of the two terms and they continue to confuse me. I also see in practise teams have raised User Stories as [Enabler][Spike], can the terms co-exist?

02:24 am August 15, 2019

Might one of these help in refining a Product Backlog item to a “ready” state, so it can then be planned into a Sprint?

Might the other refer to a planned item which defers empiricism for some reason?

04:55 am August 15, 2019

Thank you Ian for your rely. Enablers is help with refinement of PBis so that they are ready for commitment. Spikes hinder progress of committed work. Basically rewording what you said, im I correct? If so what are some of the examples, i.e. enablers are tasks such exploring a feature and what about Spikes?

08:30 am August 15, 2019

Spikes are a type of exploration Enabler Story in SAFe. Defined initially in Extreme Programming (XP), they represent activities such as research, design, investigation, exploration, and prototyping. ... Like other stories, spikes are estimated and then demonstrated at the end of the Iteration

08:40 am August 15, 2019

I typically see Enabler in the context of SAFe where there are different types of enablement work - exploration, architectural, infrastructure, and compliance. Spikes come from Extreme Programming and describe work to figure out answers to questions, promote learning, or reduce risk.

Exploration enablers and spikes are very similar - both are designed to make learning and risk reduction work visible and trackable. Both are closely related to Product Backlog Refinement in Scrum.

03:32 am August 16, 2019

Enablers is help with refinement of PBis so that they are ready for commitment. Spikes hinder progress of committed work. Basically rewording what you said, im I correct? I

I’d suggest you may wish to consider a “spike” as a Product Backlog refinement activity; a time-boxed technical investigation which is just enough to allow an item to be estimated and brought to “ready”.

If you find an item being described as an “enabler”, it may be worth querying what value it delivers itself, or how it would otherwise cause the product to be inspected and adapted. If it does neither convincingly, the so-called “enabler” could be a euphemism for a staged activity in which at least some development work is being waterfalled out.

05:55 am August 16, 2019

Thank you all for valuable definitions, it definiealtely helped me clarifying uncertaintinty around these terms.

11:51 am August 16, 2019

I’d suggest you may wish to consider a “spike” as a Product Backlog refinement activity; a time-boxed technical investigation which is just enough to allow an item to be estimated and brought to “ready”.

If you find an item being described as an “enabler”, it may be worth querying what value it delivers itself, or how it would otherwise cause the product to be inspected and adapted. If it does neither convincingly, the so-called “enabler” could be a euphemism for a staged activity in which at least some development work is being waterfalled out.

Generally, I'd agree. Scrum calls for a percentage of time allocated to each Sprint for Product Backlog Refinement. This probably accounts for a lot of work that would normally be considered a Spike in Extreme Programming terminology. Capacity for Spike-like work is built into each and every Sprint and is considered during the Sprint Planning.

However, there are cases where I can see it being used to identify and explicitly track "spike" or "enablement" work and not just simply call it part of Product Backlog Refinement. Spike work that require a significant (to be defined by the team or organization) amount of effort beyond the normal Product Backlog Refinement work may need to be made visible on a Product Backlog so dependencies between that and other work can be made transparent to stakeholders when discussing order and priority. Enablement work that delivers new infrastructure or architectural changes may need to be tracked and have traceability as part of change management and compliance or for coordination across multiple teams.

There are definitely good reasons to separate out spikes and enablement from Product Backlog Refinement, depending on the needs of the team and the organization.