13

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?
9

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.

5

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.