Spikes are a convenient way in Agile Scrum to describe discovery work needed to help inform some particularly complex or ambiguous area of a product's code or functionality. They're described in various leading websites dedicated to agile methodologies where they're given thoughtful treatment and careful consideration. They should also be launched into the sun.
An agile sprint is about delivering customer value (allowing for various uses of the words "customer value"). Spikes do not deliver value; they are a bottomless time sink for engineering effort. They are a way for the team to ask permission to learn something. This behaviour introduces an anti-pattern into the team that makes it feel "safer" for software engineers to handle complexity and uncertainty, which are integral, distinct problems in software teams that should be accepted as a matter of course. If you have code or functionality that isn't well-understood, it's probably not well-documented, poorly tested and may well be over-engineered to boot. This is a conversation that developers need to have candidly and publicly with the Product Manager. Don't dress your need to explore and learn in a trench coat and call it a spike: factor a specific block of time in to explore the problem space and commit to delivering some value at the end just like any other work item.
Time-boxed investigation or diagnosis should allow just enough time to explore a question, make a decision and deliver some value. If that means a higher than usual points estimate, be honest about that. If it means that estimate is impractically high, discuss the absolute minimum value (in terms of what you want to learn and what you will deliver as a result) required and re-estimate for that. Learn fast; fail fast, but make a decision as soon as possible on whether this area represents good customer value and warrants the time and continued effort investment.
So what are the takeaways here?
Stop hiding work in spikes
Be honest about unknown spaces and negotiate time-and-scope constrained effort with the product team as part of your usual work item workflow
Be concrete about the outcome you’re seeking (better documentation, setting a baseline, better observability…): you’re accountable for value, so be prepared to demonstrate it
As always, slice ambiguous work into small parts and stages (define your “known unknowns” and describe what’s required to surface that knowledge)
Spikes are woolly, nebulous buckets that let you hide the accountability and effort input for technical debt and the way to stop shying away from that confronting reality is to discuss it openly and agree on what the appetite for discovery really is.