XP was never as obsessed with “precision” in release planning as Scrum has become. I was taught in the XP Immersion workshop (given by Robert Martin, Ron Jeffries & Kent Beck in 2000), that spikes are not given story point estimates because they do not contribute to forward velocity on completing the backlog - they are in essence, research overhead and absorbed into the team’s ongoing story velocity. Similarly, a spike in XP does not produce production code - it does not develop an actual story in the backlog - but rather it enables future story development. Driving the spike is not actual climbing - it does not move us closer to the top - but rather it enables future climbing. When climbing, we might stop to drive a spike into the rock face. My recollection from the early XP Universe conferences in 2001/2002, is that the term “spike” comes from an analogy to rock climbing. What’s a Spike, Who should enter it, and how to word it? by Andrew Fuqua I found the practice particularly useful while maintaining large frameworks.” Further Learning The term spike comes from Extreme Programming (XP), where “A spike solution is a very simple program to explore potential solutions.” XP guru Ward Cunningham describes how the term was coined on the C2.com wiki: “I would often ask Kent, ‘What is the simplest thing we can program that will convince us we are on the right track?’ Such stepping outside the difficulties at hand often led us to simpler and more compelling solutions. The solution is to create a “spike,” which is some work whose purpose is to provide the answer or solution. Sometimes a user story is generated that cannot be well estimated until the development team does some actual work to resolve a technical question or a design problem. A task aimed at answering a question or gathering information, rather than at producing shippable product.
0 Comments
Leave a Reply. |