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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I'd like to see JIRA Spikes treated like Rally does: "Does not impact production" so that no tests are required and acceptance is automatic upon completion.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
Not true. Often the result of a spike is that NO work needs to be done. It is a DISCOVERY activity. So it may NEVER get converted to a story. But it MAY take story points to get to that point of understanding.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
How do you account for spikes in the time during a sprint? If we are using Story Points, and the team delivers on a certain velocity per sprint, then how do we account for also needing some Spikes done during the sprint?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.