Spike… Do the Right Thing [Redux on Aug 30 post]
Doing the right thing is often context dependent. I've had occasion with my current clients to discuss the concept of Spikes and how they are treated by numerous teams. I've realized that where a team currently resides in the continuum of learning iterative/incremental development has quite an effect on how I discuss this topic. The current industry norm is to treat a Spike as a type of Story. This has been reinforced by web-based tools limiting trackable items to Stories, Tasks or Defects. I've seen novice teams struggle with this notion and here's why:
Summarily, the purpose of a Story is to describe some piece of functionality valuable to, and testable by, a customer.
The purpose of a Spike is to investigate the solution options and feasibility of addressing a particular problem space or Story.
Stories should have direct customer value as well as a size estimate (representing effort, uncertainty etc) from the team, while Spikes have no direct customer value and are generally time-boxed to no more than 2 days.
From this perspective, Spikes should not be called Stories because they violate the spirit of the principal purpose of a Story (to express something of value to a customer). I think much of the confusion on this topic stems from our desire to want to name things based on how we manage them. I think people would like to manage Spikes in the same manner they manage Stories but then assume that means the Spike should be called a type of Story.
I've seen novice teams want (naturally) to do things like give the 'Spike Story' a size and then directly equate that size to the length of the time-box. This tends to negate the value of using Story Points for sizing Stories in a backlog.
Conversely, if a team treats a Spike as a Story and gives it a size of zero, that is inconsistent with the fact that they are spending time on it. It also grates against those who look for Stories which we "get for free" (and therefore give a size of 0) as a result of some overlapping work on another Story. These are subtleties which a mature team understands but a novice team, new to Stories, can find challenging.
So how about Spikes as Tasks?
I believe Spike activities have much more in common with Tasks than Stories. However, there are inconsistencies and pitfalls here as well. If a team treats a Spike as a Task inside a relevant story for an iteration, when the Task is complete, then the relevant Story should technically be removed from the iteration and returned to the release backlog (unless it is determined that the entire story can be completed before the end of the iteration) for future prioritization along with at least some of the resultant child/replacement Stories. Depending on the the size of those resultant Stories (and the team's velocity) some of them may remain in the current iteration. If we emphasize striving for completing all stories initially planned in an iteration we end up having to make exceptions for Stories containing Spikes. Another pitfall is that when a team employs "yesterday's weather" for their next iteration, they need to ignore the size of a Story containing the Spike task. Again, these things may be easily comprehended by a mature team but perhaps are contentious for teams transitioning to Agile methods, inexperienced in the use of Stories, and looking for absolutes (and THAT is a subject for a future post!).
How about neither Story nor Task?
In my experience, Spikes are generally an extension of Backlog Grooming and as such could be considered release overhead. Spikes are generally not included as part of the release backlog but they likely result in a set of more defined Stories which may be part of the release backlog. Perhaps it would be better for some teams to simply reduce team member availability during an iteration to account for the Spike time-box? After all, we do this for things like Backlog Grooming meetings. The one drawback to this approach is that there would be no explicit/transparent way for the team to manage the time spent on the Spike activity.
So why isn't a Spike just a Spike?
While the notion of a Spike overlaps the notion of Story in that both have a goal; and the notion of a Spike overlaps the notion of a Task in that both represent an activity, I think the differences between the 3 are signficant enough to warrant maintaining/managing a separate entity - 'Spike'. This is easily accomplished on a traditional index card wall, but is usually explicitly prevented when utilizing a web-based management tool. I believe this is one of the mistakes we as a community made when we transitioned to using these tools. When we were using index cards we simply called it a Spike and off we went. We didn't have to choose to create that entity as a Story or a Task so there was less confusion.
Of course this is all just semantics ... Story, Task, Spike, Backlog Grooming ... what's the big deal? The answer to this lies in the fact that we use words to communicate intent and without some consistency in the meanings of these words, it is difficult for people new to the concepts to keep it all straight. The English language itself is full of inconsistencies and similarly, it is not until one is familiar with the patterns that one can grasp and remember the exceptions.
In the end what do we care about?
I really only care that the size of the release backlog is consistent with the team's current understanding of the backlog, and that the team's velocity actually represents the rate at which they may be able to reliably and sustainably address prioritized items in that backlog. As Spikes occur, the resultant child/replacement stories will likely affect the cumulative size of the release backlog and the product owner can make the relevant business decisions with current information.
So depending on the individual team and their circumstances, any one of the 4 options might be the right thing. If you're using a web-based tool (that limits your trackable items to Stories, Tasks and Defects) to manage your iterations and your team is relatively new to the use of Stories, consider treating Spike activities in the same way you treat other iteration overhead activities.
