Yes. The basic rule is “if it takes capacity of the team to get the work done, then it should be visible in the Backlog and have an estimate.”

Estimates and velocity help Teams to understand the capacity of the Team and reason about how much work a Team can take on. Further they provide Product Managers and Product Owners with the data needed to provide forecasts and roadmaps. In order to be used this way Team's need to ensure that anything that takes up capacity is represented in the Backlog so that:

1. As work is completed, the capacity taken by that work is also captured in the form of velocity
2. As we plan for new work, the can use the estimate (vs capacity for an Iteration) to determine how much work can be taken on
3. As we look ahead beyond the current Iteration, we can use the data generate to build roadmaps and forecasts

This means that Spikes, and everything else such as Bugs, should have an estimate.

The next question people usually ask is “how do we estimate a spike when, by definition, it is research oriented, and so we cannot know how long it will take?” Two potential approaches are:

• Capacity allocation: The estimate (in points) is not used as to determine how long something should take, but rather is used to determine how much capacity we want to use to determine the answer to the question we are researching - an allocation of the teams capacity to do the research. If we find that we have used that capacity, we use this as a trigger to ask ourselves whether it is valuable to continue research, or whether we should just stop.
• Level of complexity or unknown. We use a table as discussed in How can we put an estimate on complexity?. The table would be adjusted to values that make sense in your estimating context.

In reality, Teams often use both these approaches as they work complex or unknowable work e.g. start with a level of complexity estimate and use it to determine whether to stop or continue when that capacity has been used.

Warning: not everyone agrees with this stance. There are some coaches that say you should only estimate things that add value and so velocity is like a measure of value delivery. For these coaches there is a feeling that there is no value delivered with Spikes, bugs, and so on. To me, this is a misunderstanding:

• For Spikes in particular, learning is valuable but it just is not directly evident to the customer.
• Story Points make a poor proxy for “value delivered”

• How can we put an estimate on complexity?