What is a Spike in Scrum

This question comes up time and time again and the Spike is often confused with the Tracer bullet. Adam Sroka posted a great explanation of the difference between the two on the Yahoo Scrumdevelopment group . So I am quoting Adam verbatim here - thanks Adam.

"The Pragmatic Programmers described something called a "Tracer Bullet" which:

1) Is an experimental solution that cuts through all the "layers" of
the architecture.

2) Is not necessarily time-boxed.

3) Is not intended to be thrown away.

Eric Evans talks about "Thin, vertical slices," which are the same as
Tracer Bullets.

A Spike Solution:

1) Is an experimental solution that cuts through all the "layers."

2) Is necessarily time-boxed.

3) Is always intended to be thrown away.

The reason for the distinction, IMO, is that the "tracer bullet" or
"thin, vertical slice" model is how XP teams normally work. A Spike is
an exceptional way of working when we feel we don't have enough
information to give the customer realistic expectations. The goal of
the Spike is to establish those expectations."

Spikes are a really good way for teams to figure out stuff that they don't know and need to know in order to understand the complexity so that it can be properly estimated, or quoted on or simply to find out if something is technically possible or not.

Do you even need a product backlog?

A great question was posted on scrumdevelopment group, worthy of discussion. The question posed ...

Summary

Their business moves very quickly and, more often than not, any stories that enter a sprint will have been thought up and written up maybe only two or three days before a meeting of the stakeholders and the product owner to decide what the priorities are. Anything that doesn't make it into the list for them to estimate and add to the sprint will go on the product backlog, but will generally not be looked at again for a while, if ever.

Question

To this end, our backlog is ever growing with stories that, in all likelihood, we'll never work on. Based on this, should we even bother with a backlog?

Response

Long backlogs in Lean thinking represent waste. Especially given the picture painted by this use case. Long outdated product backlogs means someone in the organization has to go through it and  keep it groomed. The longer the backlog, the longer the time required to keep the backlog updated and if it's really ever used, why bother. Important requirements will always surface again.

I personally hate not recording stories as I am always concerned that a great idea will just get lost and forgotten about. But this does lend to wasteful behavior and work.

In this scenario, it's seems like their just-in-time story elaboration is working well. So I would be inclined to recommend that they drop the notion of a product backlog. Or perhaps triage only really high priority ones onto the backlog.

Thoughts?

Jack

Remote contract workers

A question posted this morning on one of the Yahoo groups ..

" We have a Scrum team in the Silicon Valley and two contractors who work with us remotely. Although they are proficient at what they do, it has been a challenge to get them (understandably so as contractors) to be apart of the team. We have two main issues:

1) They are contractors and don't see Scrum as more than just something to do to
keep a contract.
2) Daily meetings and full conversation required for communication saturation
are next to impossible over the phone (and really poor quality, unreliable Skype
video), and despite our efforts there is a disconnect and a lack of
effectiveness felt by everyone.