Is a Spike Issue Type Worth It?

[Daniel Martin]

I recently set up a Jira project for tech infrastructure program with a 20 year old waterfall culture.  My supervisor made a random ask to add "spike" issue type to the Jira project.  I believe the need is for providing research tasks to one of the four teams using the project.  

I'm not a fan of unnecessary complexity and research describes a spike issue type as near identical to a story or task.  Yes, I could work to modify the spike issue screen to limit the fields, but is this really worth it?  Does any one else use spike issues?  Is there a benefit to having a separate issue type for research, which is currently tracked in a task?

[Ste Wright · Accepted solution]

Hi @Daniel Martin 

To add another view to this - I'd trial the use of Spike being identified via another field first, and see how much it gets utilised.

There might be some good reasons to have an additional Issue Type of Spike - for example...

• Spikes are a separate piece of work, and need to be easily identifiable on boards (with a separate Issue Type icon)
• There's different configuration for Spike's - eg. Statuses/Workflow, Fields/Screen, etc
• ...etc

But, I'd look to test the theory first. Ask your team to use Labels and/or Components to identify Stories/Tasks which are Spikes and trial this over a set period (eg. 1 month).

If there are Spikes being created consistently across the team, then I'd trial a new Issue Type - if not, I'd leave it.

The fact is I find even though lots of additional Issue Types are requested, teams end up not always using them consistently :) - so getting them to prove the need via data is useful!

Ste

[G subramanyam]

Hi @Daniel Martin welcome to the Atlassian community.

I hear you about the "spike". In my personal opinion and experience, creating a dedicated Jira issue type for "Spike" is totally worth. It's not just any other issue type for the name sake nor adds complexity to project.

I would say, it is one of the best practice for a team to have "Spike" to give room, visibility and focus on the product development strategy.

The question hear would be, how your organization want to explore "Spikes" in your Sprint planning or portfolio level planning and what type of report they will utilize out of "spikes" over a period of time.

[Sam Nadarajan]

Hi @Daniel Martin and welcome to the Community!

I feel ya on whether you need a dedicated issue type to capture what is essentially a task or to-do item for your team. 

I'd ask yourself the following questions to determine if you need a separate issue type:

• Are spikes processed differently than stories or tasks and need separate statuses (workflows)?
• Will your team need to capture information specific to a spike that is not necessary on stories or tasks (fields)?

If yes, then go with the separate issue type. Otherwise, you could add a label or use some other means to classify tickets as spikes. If your team has an issue with visibility, then a spike issue type may be worth it.

I actually was pulled into a similar discussion yesterday (discussions are still ongoing) so I'll be interested in the outcome in your case.

[Nic Brough -Adaptavist-]

I would add "do you need to identify spikes as different entities to stories" to the list of reasons you might want to have a different issue type, even if everything else about it works as though it's a story.

Some teams like to be able to work spikes as though they are stories, but be able to run a simple search for "issuetype = spike". 

But it is entirely a reporting thing.  I'd only do that if reporting on spikes was really important. 

Most teams (especially ones who don't have many spikes) are happy with "issuetype = story and (<custom field> = spike)" or "issuetype = story and comment ~ spike"