What does "Architectural Spike" mean?

Question

What does Architectural Spike mean?

I know, that this is investigation activity for unknown and unestimated tasks. But I want know more details.

• When we should do it: during Sprint or between them?
• Who should do it: whole Development Team or just a part of it?
• How serious should be a problem to decide make a Spike, instead solve this problem inside current tasks?
• How much time Team should spend for Spike?
• How we should determine time in previous question, if problem is not "estimatable"?
• What Team should do, if they don't investigate problem in reserved time?

Answer 1

Use spike to reduce the risk of a story or increase the reliability of an estimate

Spike is a term that comes from the Extreme Programming (XP) practice. The goal is reducing the risk of a technical problem or increase the reliability of a user story's estimate. The duration and objective(s) of a spike should be agreed between the Product Owner (PO) and development team before the start.

When we should do it: during Sprint or between them?

During the Sprint. The development team can propose it. It is a story to be prioritized and scheduled by the PO like any other story.

Who should do it: whole Development Team or just a part of it?

One or, possibly, two developers should be enough.

How serious should be a problem to decide make a Spike, instead solve this problem inside current tasks?

In my experience, if the risk is high or the estimate is very high based on worst case scenario, I have found a spike helps.

How much time Team should spend for Spike?

I have typically time-boxed it at 4 hours. Could go up to 8 hours in rare cases.

How we should determine time in previous question, if problem is not "estimatable"?

Just timebox it and either build a prototype/proof-of-concept or make a recommendation based on the findings during that time.

What Team should do, if they don't investigate problem in reserved time?

While you may not have a full solution, you now know more about it than earlier. Re-estimate the story based on this new knowledge and move on.

Answer 2

An architectural spike is a fixed time/variable scope PBI which is added if the team feels that more investigation is needed in order to maximize velocity (or to get better estimates).

Practically, the spike consists in a series of investigations centered around finding solutions to one or more problems. It's not about writing code. The deliverable at the end is generally "knowledge" (as a document, a presentation or whatnot).

It is generally like another sprint and does not require the whole team from the point of view of Scrum. It should always take less than a Sprint.

There is no specific bound in terms of "seriousness". A team can always suggest a spike, but they need to convince the Product Owner to actually prioritize it!

Normally, when teams don't feel confident to estimate, they are probably pressured. It is very rare that a story can't be estimated. Maybe the story is simply too big. Stories that take a year are very different from stories that take a day.

In any case, if you can't estimate it, simply guess, or use the current average size. Work on it, a better estimate will come later if necessary.