How to integrate a Spike with Scrum

To reach Sprint Planning 2, the team must have had enough confidence (in Sprint Planning 1) to commit to a Sprint Goal, and to have estimated (e.g. relatively sized) each requirement. In other words, they must have expressed reasonable confidence in their ability to deliver a potentially releasable increment, even though the technical context is unknown to them.

Assuming that's all the case, then so far so good.

Now you have a choice. I'd agree that the authoring of spike stories is reasonable, as long as they are kept off the Product Backlog. The team would have to introduce them directly into their own Sprint Backlog since they are part of their own plan for delivery, and do not (in themselves) represent product value. However, this is a controversial practice and some authorities do not recognize this type of story as a valid construct at all.

Another option is (in Sprint Planning 2) to identify "spike tasks", each of which will anchor the other tasks for that story into an appropriate technical context. That's probably a more defensible choice. Task identification is generally accepted as being entirely at the development team's discretion.

Hello Pablo

I doubt on the estimation done by team in SPM 1 if they don't know how to implement the story. I can understand there can be some %age of uncertainties. Assuming this is a new project/product and all team members are new, I don't mind doing spikes in first sprint for getting the estimation for future sprints however it should come from the team not PO. As a PO I would put a story for the required feature and if team feels that they need a spike before start working on that feature then PO should create a spike. It doesn't make sense to have the spike and actual feature in the same sprint. For spike I generally put in the acceptance criteria -

Create/update PBIs for feature X
Put estimation for all PBIs related to feature X

Cheers
Sanjay

A Spike is a timebox for the Dev Team to get enough knowledge for estimating a story. The value for the product owner is, that he can then do his release planning, which would otherwise not be possible. During a Spike, the Dev Team can create a functional prototype, even neglecting the DoD - but it has to throw it away afterwards. It's just for learning, not for creating product value.

I usually do not have Spikes with experienced teams. With unexperienced teams they do have some value, especially in contexts where Agility is not yet fully understood and the wish for precise estimates is high.

Usually, the Product Owner does not carry around Spikes in his Backlog. Only when during the Sprint preparation meeting the Team can't estimate something and asks for a Spike, he might negotiate the timebox, take it on the backlog, and only keep it there to the next Sprint Planning meeting.

While this is a controversial practice, I have seen situations where this tool was benefitial. Just make sure the Scrum rules aren't broken!

Hi Dominik,

Thanks for your response.

A question regarding the following:

A Spike is a timebox for the Dev Team to get enough knowledge for estimating a story.

Lets say that the project have 20 stories and the team isn't confident enough to estimate any of them due to the lack of domain knowledge and the framework, libraries, tools used within the organisation. As i said, the developers are All external (experience) consultants.

What would you advise when it comes to using Spikes? Do a Spike for every story? Is it common to do a Spike Story first and than immediately after that the actual story wothin the same sprint?
Or do they always need to be seperated?

We have had cases where experienced developers only needed 1 or 2 days to learn something. From there, they were able to jump right into the feature story. All within the timebox of our sprint.

My only point is that one should not constrain spikes and stories to separate sprints. There are real world cases where it simply makes sense.