Spike in Scrum?

Why would the evaluation and prototyping you describe be necessary? Would it be done in order to refine items on the Product Backlog?

What has been working well for us is that the BA and PO review any new item the second it gets added to the Product backlog.  The BA (me) identifies any likely place where the story is unclear or needs to be fleshed out and gets the necessary information to create a set of Acceptance Criteria.  We then do a formal grooming session where the developers review the story and decide whether or not it's ready to be worked in a future sprint.  Since we aren't working on a single product but rather maintaining a set of applications and tools, this seems to work fairly well.  

If I notice something is going to need additional developer time to research methods or go through code, I raise that to the PO and the team.

Thanks Ian, thanks Larry

Should you decide to move your infrastructure to the cloud, you need to evaluate some suppliers (AWS, Azure, Google,...) and do some tests/prototypes.

The same applies when choosing a big framework.

It would take some days.

@Larry, your solution is smart and perfect for relatively small items.

How would you approach such a big activity?

Thanks

Marco

Myself I would break it down into stories and then add the stories to the backlog.  Do the same process as you would for a normal story in trying to get as much information up front, then review with the developers on what information they need to do the work.  The work may not be development of an application but instead the research and testing required to make a decision on which platform to use.

Myself I would break it down into stories and then add the stories to the backlog.  Do the same process as you would for a normal story 

Agreed, developers can help a lot here to break down the stories and tasks for PO as are more technical things.

I encourage my teams to not put Spikes in the Product Backlog.  Instead, I encourage them to put Spikes directly into the Sprint Backlog.  And that only happens if there is something that is blocking the team from being able to understand something in the Product Backlog.  By doing this I have found that they want far less Spikes and will instead lean on making stories more focused (or smaller if you prefer) so that any unknowns that are encountered can be dealt with as the information is found.  

Remember, the Dev Team forecasts a sprint backlog based on what they know at the time of planning. If they uncover something during the sprint, they inspect and adapt. If the sprint backlog needs to be changed, you determine if that change endangers the sprint goal.  If so, conversations occur with PO to rethink. If not, compensate and move along. 

My experience has been that teams tend to use Spikes as a way to thoroughly create specifications (old way). Much of the agile varieties actually encourage you do things without knowing everything. That is the where agile excels and allows you deliver incrementally.  Too many spikes sounds and smells a lot like waterfall to me. 

@DanielWilhite I'm with you. Too many spikes sounds like waterfall to me too - otherwise, we will need a new Kanban to control spikes only.

The updated Scrum Guide says: "The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team."

I believe Spikes match this definition as they help to make informed decisions on what can hugely affect product development in future.

However, there should be a good balance between Spikes and decisions which are made during regular feature development.

Decision to follow Spike approach should be agreed with the whole team and good reasons for doing this should be provided.