No Spikes
I thought about writing this post a while ago but it has recently come to mind once again. A Spike is ...a timeboxed experiment meant to gather information to reduce risk and enable more accurate estimates for complex user stories. -- Agilemania - What is an Agile Spike Story? I'm not a fan First off, let me be clear I'm not 100% against completing Spikes. Perhaps 99% against them though. The big issue I have is the tendency to over-rely on them for even the tiniest of uncertainty or lack of clarity or direction. I'm generally of the opinion an engineering team should be skilled and knowledgeable enough, plus have the confidence, to 'jump in' and engineer a solution. However, let's dig a little further. The attributes of a Spike Time-boxed ⏳ OK, so we're not commiting (if there is such as thing) to an estimate, but instead we will limit the time needed to gather the information required. How large is this 'time-box'? A day? A week? A month? If we can come up with an accurate time-box, then we have some certainty of the unknown. Can that not be factored into the 'uncertainty' when estimating the actual Story? What happens if the Spike gives us what we're looking for? Then what? The findings get written down, the prototype put to one-side (to decay) and the team switches context to something else. When the team then come back to start the implementation, are the findings of the Spike still accurate? Do they even make sense / do we understand them still / would the prototype still work? We probably need to spend even more time refreshing our memory. What happens if we still don't have enough information at the end of the time-box? Do we extend it or commit to a new Spike? - How long for? ⏱️ Do we stop and do the actual work? - So what was the point of the Spike if we are going to get going without all of the information anyway? We've just wasted the time it took to complete the Spike rather than just trying to get the work done. Winner - Story Experiment
I thought about writing this post a while ago but it has recently come to mind once again.
A Spike is
...a timeboxed experiment meant to gather information to reduce risk and enable more accurate estimates for complex user stories.
I'm not a fan
First off, let me be clear I'm not 100% against completing Spikes. Perhaps 99% against them though. The big issue I have is the tendency to over-rely on them for even the tiniest of uncertainty or lack of clarity or direction. I'm generally of the opinion an engineering team should be skilled and knowledgeable enough, plus have the confidence, to 'jump in' and engineer a solution. However, let's dig a little further.
The attributes of a Spike
Time-boxed ⏳
OK, so we're not commiting (if there is such as thing) to an estimate, but instead we will limit the time needed to gather the information required. How large is this 'time-box'?
- A day?
- A week?
- A month?
If we can come up with an accurate time-box, then we have some certainty of the unknown. Can that not be factored into the 'uncertainty' when estimating the actual Story?
What happens if the Spike gives us what we're looking for?
Then what? The findings get written down, the prototype put to one-side (to decay) and the team switches context to something else. When the team then come back to start the implementation, are the findings of the Spike still accurate? Do they even make sense / do we understand them still / would the prototype still work? We probably need to spend even more time refreshing our memory.
What happens if we still don't have enough information at the end of the time-box?
- Do we extend it or commit to a new Spike? - How long for? ⏱️
- Do we stop and do the actual work? - So what was the point of the Spike if we are going to get going without all of the information anyway? We've just wasted the time it took to complete the Spike rather than just trying to get the work done.
Winner - Story
Experiment
What's Your Reaction?
