Lets say that the project have 20 stories and the team isn't confident enough to estimate any of them due to the lack of domain knowledge and the framework, libraries, tools used within the organisation. The team might be new to that module, so pushing the team to start implementation without preparation would add too much risk to the project. > My recollection from the early XP Universe conferences in 2001/2002, is that the term “spike” comes from an analogy to rock climbing. Kent dubbed this a Spike. It will help the team to estimate the new enhancements accurately. The important thing about the time box is that it limits our investment, at least until we make a conscious decision to invest more.I was co-training a CSM class with Chet Hendrickson just yesterday, and the question of etymology of ‘Spike’ came up. I found the practice particularly useful while maintaining large frameworks.”At the outset let me say that I am new to agile, hence I’m googling definitions.Visit the definitions by clicking on the letters in the navigation bar, or you can search for a term, above.what happens to spikes that run out of time without reaching the understanding?Pingback: 스파이크 (Spike) • Agile PracticesPingback: The Ultimate Introduction To Agile Project Management – NotesPingback: On Building Tools for Developers: Heroku CI | Rake™That’s a good analogy. A spike is a user story for which the team cannot estimate the effort needed.
Often, the outcome is a more refined estimate for how much work the actual business objective will require. Once the high-level architecture is decided, the detailed level design can be done as part of the sprints.Opinions expressed by DZone contributors are their own.In some cases, the user needs are not clear enough for translating them to well-defined requirements. The output of a spike is an estimate for the original story If the requirements are not clear, the estimation could also be negatively affected. And, by nature of trial-and-error, it’s possible that a “Spike” task could lead nowhere.
An Agile Spike is a great strategy to employ if you need to take some time to do work that is not related directly to a user story or requirement. The exception is if the result of the spike is information that will be used by stakeholders outside the team. It features scrum tools like user story map, product backlog management, sprint backlog management, task management, daily scrum meeting, sprint planning tool, sprint review tool, sprint retrospective tool, burndown, impediment, stakeholder and team management.Like other stories, spikes are put in the backlog, estimable and sized to fit in an iteration. What are the cons? Chet was there when it was named ‘Spike’, and he said it was actually named after the really long nails that hold a gutter on to your house.
“how long it takes to update a customer display to current usage, determining communication requirements, bandwidth, and whether to push or pull the data”The technical spike is used more often for evaluating the impact new technology has on the current implementation that the team needs experiment a new technology to gain more confident for a desired approach before committing new functionality to a timebox.A powerful scrum software that supports scrum project management. That is, the team is creating something of value that has been requested by stakeholders.Something that interests me is, a spike is described asA task aimed at answering a question or gathering information, rather than at producing shippable product. So, to me, it would be overkill– and perhaps improper– to point out Spikes. The term is used in agile software development approaches like Scrum or Extreme Programming. *Why* did he dub it a “spike” as opposed to an “auger” or a “spear” or a “fruit salad”??? What are Spikes in Agile?
They are just part of the normal product backlog refinement work that team members do on an on-going basis.
The micro-level work can start in an iterative way based on the high-level design. When climbing, we might stop to drive a spike into the rock face.
I can, of course, point spikes for iteration capacity planning but then not include them in velocity calculations, but, silly as this may sound, I think that will discourage my teams from accepting spikes. A user’s spike (story) should be determined according to what the user states during basic development project phases and geared toward user software requirements. They say gear, protection, pro, pitons, ice screws, bolts, hangers, nuts, cams, friends, chocks, copperheads, hexcentrics, cowbells, etc.
Very much like the self appointed “gang of four” and their “design patterns” some of this agile terminology obfuscates or creates vagueness of purpose. "The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases." Spike results are different from a story, as they generally produce information, rather than working code.