Impact on velocity from timeboxing spikes vs. story pointing stories.

I want to know from the community if it's a good idea to story point spike?

Velocity is the rate at which work is Done. Would it therefore make sense to try and "story point" a spike activity at all, or would doing so interfere with this measure?

If not, how would you separate timebox of spikes and story points?

Is the spike necessary for the creation of a Done increment this Sprint?

If it helps clarify work that may be undertaken in future Sprints, why not simply reserve an appropriate capacity this Sprint for Product Backlog refinement activities?

There seem to be a lot of false assumptions here. I don't know why you can't apply story points to spikes, can't estimate stories in time, need to use spikes and stories, can relate points to time, or that it's the Scrum Master's responsibility to create a process for the team. I'd start by thinking though these assumptions.

It's also not clear what the problem the team is facing. Expressing a specific, solvable problem may be more useful. Is the team having problems planning their Sprint or achieving their Sprint Goal or something else? If not, why the concerns around spikes and estimates?

Hi Thomas, 

The pain reason why I wanted to ask this question is because it is a scrum master's role to create an intuitive process for the team to follow. If we story point stories and timebox spikes, its not on the same scale. This is why I am finding it important to ask this question.

The reason why this question was brought up was because a dev lead brought up this concern to me in the team. He believes that when there are gaps in the process, it may hinder the team down the road, which I can completely understand! Estimating spikes and stories differently and combining them to influence the velocity might not be the best process improvement. It influences velocity which is the primary measure for which we sprint plan around!

Where is it stated that

it's a scrum master's role to create an intuitive process for the team to follow

The Scrum Team should sort out its own specific processes and practices. 

The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.

I think you can support the team in finding what is effective for them and you can leverage empiricism as your foundation. What supports better Transparency? How will you Inspect with that Transparency? And so on.

Many great points above about practices you can leverage. Spikes can be part of the refinement process, or they could be backlog items that are sized. I think so long as you are consistent in how you approach each, the rest will balance out. You are either taking time away from working on other value producing backlog items (which will influence your measures), or you are accounting for all by following a size all the work approach.

The pain reason why I wanted to ask this question is because it is a scrum master's role to create an intuitive process for the team to follow.

It is absolutely not the Scrum Master's role to create a process for the team to follow. The Scrum Master should have the knowledge and experience to be able to coach the team on effective practices and how practices impact each other and to facilitate conversations about the team's way of working, but a self-organizing and self-managing team will create their own processes.

The idea that an expert comes in and creates the team's processes and procedures is a Tayloristic way of thinking.

If we story point stories and timebox spikes, its not on the same scale. This is why I am finding it important to ask this question.

I don't understand why it is a problem that pointing stories and timeboxing spikes is a problem. Why does the scale matter?

The reason why this question was brought up was because a dev lead brought up this concern to me in the team. He believes that when there are gaps in the process, it may hinder the team down the road, which I can completely understand!

I'd agree that gaps or misalignments in the process may hinder the team, but I don't see any evidence of such gaps or misalignments at this point in time.

Estimating spikes and stories differently and combining them to influence the velocity might not be the best process improvement. It influences velocity which is the primary measure for which we sprint plan around!

This is a difficult problem. I'd even say that this is one of the biggest, if not the biggest, problems with story points (and also t-shirt sizing). There is no way to compare measure of size or complexity to time.

One option would be to base velocity only on the number of story points completed. If you decide to allocate more or less time to refinement (and there's no real difference between a spike and the notion of Product Backlog Refinement), you can adjust the number of planned story points up or down. However, since you can't map points and hours, there's no good way to say how much you should change your planned story points.

Another way would be to estimate all work in hours. If you're going to estimate, this is my preferred approach since you can determine capacity in hours and check your planned work against capacity.

You could also look at no estimates approaches and instead use flow metrics to get insights into the completion of work and make forecasts for the near future. This would be my preferred approach.