YDS: Should Scrum Teams Put Spikes in Their Sprint Backlog?

[@kirkmathes3525]

Also, how do you differentiate between spikes and normal backlog refinement that helps you better understand a future story?

[@mp9350]

I find a majority of time that spike time boxes go way over and usually the developers end up completing the difficult task they wanted the spike for. For example, my devs will say they need a spike to understand some part of the application before they work a PBI. The PBI will even be in the same sprint. Well isnt part of working a PBI to band together to talk about the issue and work to resolve it within the sprint? It just seems that maybe that PBI will have a higher effort due to uncertainty and the PO should just plan for that or maybe not bring so many items in to the sprint that time around.

[@olegsokolov824]

Are you re uploading videos?)

[@susangenger5924]

Im early

[@scottf9044]

The better question is "how do you define a spike?" They are grossly overused for mostly what they are NOT intended for. They're used as an excuse to just do more analysis, which then becomes waterfall. Watch teams that suggest spikes. They'll estimate it at 1-2 days in the sprint...then automatically assume they can't start the implementation until the next sprint. that's an automatic 2-week delay and its because they really intend on doing way more than 2 days of analysis. Suggest to them they complete the spike in the fist 2 days of the sprint and then move immediately into implementation. When I suggest this most teams are silent because the simple thought of that freezes their brains.