I've just recently come across an agile term called SPIKES.
How do you, or how can you, use this in JIRA - specifically within Scrum Boards?
Any info would be useful.
Lot of people do this creating an issue type named Spike. This will help you differentiate spikes from actual stories or tasks.
As quoted in the link, "the purpose of the spike is to gain the knowledge necessary to ...". Hence, a story or task will come out of a Spike and and you can link it back to the Spike using the JIRA issue links (for traceability).
Spikes will be estimated for a specific amount of time and can be added into the boards just like you add stories or tasks.
So, what are the different workflow status that can be associated with Spike? Are these the ones Assigned, In Progress, Pending, Review etc. but since it is not deployed or doesn't go to the development what status should we use when the investigation is done on the spike and it is ready to be closed against a story or stories.
Thank you for your help in advance.
Spikes are only used with research and documentation of it. That should be pretty much straight with ToDo, InProgress and Done. The output of the spike can be used to create epic and stories. I would prefer separate workflow for spike if you are using more statuses.
It is an investigation activity to gain knowledge to solve a problem. For example I need to write a piece of code to publish results, whereas the data sits in legacy system. I'm not aware of the location of data. I investigate to gain knowledge to access data from a specific location. Unless it is a high priority task, I may not take this story into the current sprint (publishing results), because I have no knowledge of the location of data. I create a spike, approach the legacy system experts and get the knowledge of the location to extract data. So I create a spike. As Maitrey said it is To do (for what), arrange a meeting with legacy expert (In progress) and once you gain the knowledge of location (Done). Now I will take the story of publishing data once this discovery is done. Thanks
That may all be true, but it misses the point: There's no way to mark it "Does not impact production" so that no tests are required and acceptance is automatic upon completion. Our GCR staff says no story can be complete unless it has test cases approved, etc. UNLESS they are marked "Does not impact production." It's that simple.
Everything is an issue in Jira. Like a story, task, spike is also an issue, whereas a spike cannot be treated as a story because it is termed as a spike because of lack of clarity. The agile team should self-assign the responsibility for investing and conversion of it as a story and the time required. The assignee who investigates the spike allocates the time to resolve (Not Story points). Once resolved it should converted as a story.
Spikes are traditionally not assigned story points as there is no guarantee they will deliver value to the customer.
Also, if you have a customer who is working very closely with your team, they may be looking at points per sprint as a measure of value. Having too many pointed spikes in there could confuse that measure.
Spikes are in effect a technical debt owned by the team, and as such from an accounting POV they are worn by the team in much the same way as rework and bugs.
We just put the word SPIKE in the title and abuse the rest of JIRA into passive submission when the SPIKE is updated with discovery information. Then it is closed complete - again with all the abuse required by the JIRA system.
We have both SPIKE Features and SPIKE User Stories. It just depends on what level of detail is needed for the investigation at hand.
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events