Question: A technical challenge arises inside the Sprint

QUESTION- During the implementation of a story, a scrum team notifies the scrum master of a technical challenge

that is causing a delay. What should the scrum master advise the team to do?

Again, the full details of the situation are unclear. How much delay (past and future), for example?  All of these might be discussed a bit, so that all agree on the facts of the situation better, and so we move toward probabilistic better outcome.  To me, it is quite common that one must decide without knowing everything.  It is often as Rihanna said: Shut Up and Drive.

A- Implement the story since the team is running behind schedule

Nope. Not likely the best.  If it said “do the best you can to implement the story…”, then maybe.

I also assumed that the technical challenge was a “blocker”, that is, it was “I do not know how to do it”, not “I cannot decide whether to do it this way or that.” If it were the latter, then “just do it” (aka fail fast) might be the better way forward than “let’s think about it a long time”.

B- Create a spike to finalize the story’s technical approach

I think the Writer was thinking of this as the correct one.

The Spike MUST be small. (Well, I am assuming the story is fairly small.  That is, the Team has at least 8 stories of about the same size in this 2 week sprint.)

The raises to my mind the correct answer: The Team should have discussed the technical issues before taking the story into the sprint. So that this problem in the sprint (at least a problem of the size worthy of a question) never arose.

C- Transfer the story to a scrum team experienced in solving similar problems

Nope. I am totally ok to ask for help outside the team, especially if we know who to ask, and by asking we are not killing anyone (an american expression, maybe does not translate well).

This possibly COULD be the correct answer to the Writer.  Especially if this story will be just TOO hard for our team with our current skill sets.

D- Ask the product owner to reduce the story’s priority and wait until more technical details are available

Nope.

Well, it could be an ok answer, for what – to me – would be an edge case.  So…    Imagine there are no experts outside the team.  Imagine that the technical problems are hard. Imagine that therefore the spike would be so large that to do it inside the sprint would really kill the sprint.  These things are possible, but I hope unlikely.  Hence, nope.

So, we think B is the likely best answer in real life. First thing to try, in real life.  How big is the spike?  Hm. I am thinking half-day for one or maybe two people. And even though uncertain, they must recommend an approach after that timebox.  Study hard mates! (in that timebox).

Note: Spike is NOT a defined term in the Scrum Guide. In fact, the word is not used.  So, for relative newbies to Scrum, this is not a fair question.  First, not everyone even knows the concept of a research story (although they might do some “research”). Second, some people do them (in some sense or other), but they do not call them spikes.  So, for relative newbies, it would be only fair to define the term.