Spikes v Discovery tasks (When and how to use them)

[Mark R]

I am trying to understand whether to and how to use Spikes. As I understand it, Spikes are used to gain the knowledge necessary to complete a story or a task? Kind of like discovery work? Is this correct?

I am working with a Kanban board and currently when a user story requires some discovery in order to complete it or to add enough detail, I create a sub-task as part of that user story specifically for the discovery work. I'm not sure if this is best practice.

Some examples of discovery tasks may be:

- Look at the feasibility of using different 3rd party tools for gathering customer feedback, and agree on the approach

- Engage different teams within the organisation, to provide enough detail in the user story so it can be started

- Investigate what information a 3rd party requires via the API to process an order - the outcome of this would be documenting what information a 3rd party can accept for an order/recommendation on what we should send to complete the journey

I'm wondering whether I should create a Spike issue type and in what scenarios I should use it (any of the above)? What are the benefits of using Spikes?

Many thanks

[Bill Sheboy · Accepted solution]

Hi @Mark R  -- Welcome to the Atlassian Community!

Your team's answer depends upon how you work.  Do you have discovery and delivery pipelines, or one value stream, or some other workflow?  When discovery is built into your steps, maybe you do not need a separate type of work item to answer questions.  Maybe it just happens during refinement.

Otherwise...

"Spikes" can be a helpful tool for teams to answer a specific question. Some teams consider three different types of spikes, following the ideas of Mike Cohn (spike user stories), or Chris Sterling in Managing Software Debt: Building for Inevitable Change:

• Research -- "When a team does not already have a potential solution to an issue or for an upcoming feature, they have to conduct some research".  The specific question here is something like, "How would we do <X>?"
• Spike -- Throw away code to answer a specific technical question/challenge
• Tracer Bullet -- Production ready code to answer a specific question, such as trying something out with production use to check usability and value. Think of this as a thin slice through a user story.

If you do not use spikes often, creating a separate issue type may not be needed. Instead in Jira, you could use a label, component, or add a prefix to the summary to indicate the "spike" nature of the work.  And if you later find you need them more, you can add the issue type at that point.

Best regards,
Bill

[Mark R]

Hi Bill Sheboy, Thank you for your response and the definition of the different types. I can see the team potentially using all of these at some point.

We currently have a single pipeline with a 'Discovery' column in the Kanban board. Generally, if a user story requires some discovery, a sub-task is created for the story (like one of the examples I mention above) and this moves into the Discovery column, and then to 'Done' at which point there is enough info to progress the story (or not).

Alternatively, there may need to be a piece of discovery done that is not related to a specific story. In this case, we generally just create a Task for this work - I think this generally aligns to the 'Research' type above. Perhaps, here is where I could use the spike prefix to call this out.

Based on what you've said I don't think we need a new issue type at this point.

Thanks again

[Bill Sheboy]

Hi Mark,

I am glad that helped.  Please also consider periodically checking how many request items needed some discovery or spike-like work.   That may give the team further insights in ways to improve.

Best regards,

Bill

[Mark R]

Thanks Bill, I will keep an eye on how much discovery/Spikes we are using. This could be something discuss in retro's if we find we are doing a lot.