Follow-on stories to spikes

One of my ScrumMasters presented the following scenario about spikes:

Our team lead asked me about this and I wasn’t sure how to answer him. So I hope you can help. 

We have a case where we have a spike story in our sprint. We have assigned some points to the story, say 3. After work on the spike is done we will create a new story based on what we learn from the spike. We don’t know the number of points to assign to the new story until the spike is done. 

This isn’t a problem if we put the new story in the following sprint. The problem is what to do if the new story is in the same sprint as the spike. 

Here’s my guess as to how we handle this situation and get all the ‘done’ credit we deserve: We assign the max amount of points we think the new story will take, say 8. Then if the story turns out to be less, say 3, then we pull in 5 points worth of stories from the back log. That will keep our total sprint points matched with our prediction. 

Is there a better way to handle this situation?

So, a team has two stories A (the spike) and B. B should NOT be pulled into a sprint until it is "ready." Remember, "ready" means that the story has acceptance criteria and an estimate in story points. Until A (the spike) is done, you don't know the acceptance criteria and estimate for B, and is therefore, not ready.

For a great exposition on the impact of ready stories see this article by Carsten Jakobsen and Jeff Sutherland: Scrum and CMMI - Going from Good to Great (Are you ready-ready to be done-done?).

If you want A and B done in the same sprint, the only logical strategy is to plan for A during your sprint planning and leave B on the product backlog. Once the spike is done, the team needs to work with the product owner to determine the acceptance criteria for B and put an estimate on it - making it "ready." Then, B will be "ready" and can be "adopted" into the sprint if the team feels like they can do B plus the rest of their planned stories.

Assigning the max amount of points to B is just sand-bagging an unknown risk. Avoid that. Teams are more productive when they plan stories that are ready because they don't have to go back and forth during the sprint to get more clarity on stories with the product owner. 

Teams that adopt stories consistently show that they should plan to do a higher target velocity. Teams that have consistent unplanned work show that they are not prepping the backlog effectively. There is a sweet spot you have to find as a team. 

This A (spike)/B pattern is a rare occurrence for teams. Training the product owner to know that spikes run ahead of the real story implementation helps remedy this dysfunction.