What is the best way to have a spike story and be completed in the same sprint?

[Rachana gupta]

The spike story is not completed in multiple sprints which is effecting the sprint velocity? What is the best way to have a spike story and be completed in the same sprint?

[Suzi Ocello]

What is the best practice when a Spike sits in the 'waiting for acceptance|approval' state too long. It is my assumption it should not be used as a 'task|note' board and if the 'approver' is unable to get to it, it should be put on the backlog and put in a 'parking lot' state. Can someone offer some words of advice here please. I have Spikes that have been in this state for going on 4 sprints and it is killing my velocity. Any guidance is appreciated.

[Scott Theus]

Hi @Rachana gupta , welcome to the community!

I recommend not including spike stories in your sprints; they don't have story points and you're right, they will impact your velocity. Instead the Scrum team self-assigns the spike and conducts the research outside of the sprint and uses it to define/estimate stories for following sprints. 

Since the spikes don't have story points and are not part of a "potentially shippable product" they should be counted as project work through time tracking and treated like other job duties and administrative work that members of the team do outside of sprints. 

Hope this helps,

-Scott

Edit: I manage non-development issues that don't fit into sprints through Kanban boards in the project using filters on issue types, teams, components, etc. You could do the same for spike stories, that would give you a way to track them easily without impacting your sprints. 

[Caesar Padilla]

Scott - Spikes do have story points. The idea of spikes is to try to accommodate additional work that was not foreseen at the start of the sprint or it is perhaps the result of wrong estimation on a user story. Therefore, if the team deems necessary to add more work, the spike will provide the additional estimation points needed to complete the work in a given sprint.   

[Matheus Oswaldt]

I agree with Caesar.

And to add: I think that's the key to a great Spike, it needs story points and maybe a time boxed.

When we are studying something, it's never enough. So, if you don't measure time and effort to this task, it will perpetuate through the sprints. 

[Matheus Oswaldt]

Ah, and of course: A clear goal to the Spike is good.
What are you trying to accomplish when it ends?





Maybe a Spike called "Backstage Study" will be bad to your Sprint.
It's better to be something clear, like: "Study what and how can Backstage connect our stuff?"


It may answer things like "Is it better than what we do today?", "How much time to implement?", "How much it will cost?", "It matches with the tools and services we use today?", etc.