I periodically do a coaching circle as a service to our agile community. I invite anyone to it and it’s free. Think of it as a Lean Coffee format discussion with folks looking for coaching advice.
This question came up the other day:
I'd like to hear how your teams handle spikes - do spikes have acceptance criteria - yes/no? Do spikes have story points yes/no?
And it generated quite a nice discussion around the idea of spikes. And it made me think about whether I’ve ever written about them before. I was shocked to realize that I really hadn’t done a deep dive into my thoughts on spiking. Well, here goes nothing…
Definition – have a definition for your spikes. Be clear about their overall intent. That is, to increase your knowing, details, understanding. It also includes decreasing your risk of simply diving in an being surprised during the sprint.
It’s an acknowledgement that – we don’t know enough about this story, so let’s take some time to figure things out.
Perhaps use a set of past spikes (reference stories) as a means of determining what are good spike candidates or situations.
Where do they come from? I think they come from the Product Owner and Team discussions in Backlog Refinement. They should:
Narrow the estimates
Increase the understanding of the story
Increase the implementation (design) ideas & approaches
Move the team from not knowing to better knowing
Open the door to creativity & innovation
In general, taking stories “off line” to a spike should create smoother and healthier backlog refinement meetings.
A Story – I think a spike should basically “look like” any other story you’re working on. It should be:
Written in the same format
Be part of your Backlog Refinement activity
Be intentionally incomplete
Hold to the 3 ‘C’s of User Stories
And be placed in the Product Backlog for priority-based execution.
Estimation – there was quite a lot of debate in our coaching conversation about whether to estimate or not to estimate spikes. I usually recommend estimating them to create the space in the sprint to properly focus on the spike. Point it as you would any other story to create “space” in the sprint and velocity for the work. Nothing’s free.
Code, code, code – I love it when a spike produces code. It doesn’t have to be “production quality” code. Simply code that was implemented to increase the team’s knowledge. And this is actual knowledge by doing. Not simply reading or by implication. I’ve found that the more code that is produced the less risk there is in implementing the spike outcomes.
More Stories – one of the outcomes of a spike, at least to me, is a set of more thoughtful stories (features, stories, a hierarchy) and the implementation (flow) guidance amongst them to fully complete the request behind the spike.
And, of course, these all need to be refined. Which is certainly not a part of the parent spike.
Pairing – I love, love, love it when a small cross-functional group takes on a spike. I think it creates better perspective and better knowledge. This would include developer(s) and tester(s) and others as required. And the estimates (and timebox) should accommodate all of the folks collaborating. Wow – shared ownership!
Demo or Review – there’s always a BIG question as to whether you bring spikes to the Sprint Review. I always say – it depends. It’s a team decision whether it would add value to the team’s transparency and increase feedback. I would stay away from absolute positions like bring all or bring none. Instead consider each spike on its own merits and lean into…transparency.
Acceptance – one of the strongest aspects of a User Story is the notion of acceptance (done) criteria. And I think it applies even more to spikes. I want you to think carefully about bounding the spike’s focus with your acceptance criteria. Think of these as the deliverables or outcomes from the spike. Good examples of outcomes include:
Prototype code
Design
Plan steps
Further detailed requirements
Review & agreement steps (Ex: think design review)
As set of thoughtful stories
Execution flow
Environment setup constraints
And the list goes on…
Timebox – in addition to estimating the size and scope of a spike, I’ve found it useful to timebox spikes. If you don’t do this, they have a tendency, in my experience, to go on-and-on under the banner of filling in all of the blanks. Remember, stories are intentionally incomplete, so the spike isn’t intended to answer every minor detail. And remember, if you fill the timebox without completing sufficient knowledge gathering, you can always do another, re-focused spike.
Not just technical – spikes aren’t just for development or technical stories. They can be useful for any need for better understanding. For example, talking to various clients to get a better understanding of their problem (requirements). Trying to figure out how to test the story (testability, environment, data, etc.). Trying to figure out the cross-team dependencies of the story (internal teams, external teams, 3’rd parties, waterfall team hand-offs, etc.). Point being, a spike can and should de-risk most of the risk and ambiguity associated with the story, wherever that is.
Anti-pattern: 0% or 100% - I see two typical anti-patterns with spikes. Either teams don’t do them at all (extremely reticent) OR do them for nearly every story (traditional view to requirements). In either case, this is a really BIG problem. While there aren’t any rules for the right investment ratio, I usually recommend something like ~20% as being a fairly reasonable target for a spike ratio in the Product Backlog. I’m using Pareto here thinking that spikes usually surround complexity and that most of your complexity (80%) resides in 20% of the stories.
Wrapping Up
Whew!!!
When I first started writing this, I had 8 considerations, then 10, and finally 12. So, the scope of this increased unexpectedly. I guess there’s more to spiking then meets the eye?
I’ve been coaching to these points for the better part of two decades. But it’s nice to finally capture all of them in one place.
Do you have to do ALL of these? Of course not. They’re not laws or guidelines. They’re simply considerations.
However, I do hope you consider all of them before discarding the idea.
Stay agile my friends,
Bob.