What is a Spike, you ask? Well, spikes may happen when you realize you don’t have enough information to move forward with the User Story, and you need to do some research or investigation of the feature or functionality before you can start building it. Some people also call these “Research” stories.
I ran into a situation like this recently. I was reviewing a User Story for a feature to include some pretty pie and bar charts in a mobile app. The development team read the stories and started giving me the “are you kidding me?” look. They immediately said they had no idea if or how something like that could even be done. We stopped dead in our tracks and split out a spike for the team to investigate the possible solutions to meet the business need.
A spike probably wouldn’t be written in the typical User Story format. It would probably look more like this:
At the Sprint Review, the results of the research story would be presented to the team, and (hopefully) a decision would be made on how (or whether) to move forward.
This is really a useful tool when a team is uncertain about their options and doesn’t have a clear idea of how they will deliver a working solution. It gives the team time to do their homework and come up with the best available options to solve the problem.
One thing I will add about Spikes is that they should be used as an exception, not a rule. If you start doing this frequently, you might want to evaluate why it keeps happening (the 5 Whys or Ishikawa techniques are good for root cause analysis). Perhaps your requirements are vague, or the story is too big or complicated.
Simple to Complex
Another great technique to split large User Stories into smaller ones is by starting out with simple core functionality, which can provide the basis for gathering feedback from users and using that to inform what should be added next.
This is very similar to starting with a minimum viable product and then building on it. But in this case, it could be even simpler. With this method, you will split your stories and pare them down to the most basic, core elements – deferring other stories until later.
Let’s revisit the fictional Recipe app. Imagine we are just starting to build this app. At the beginning, the ONLY thing we really need is a list of recipes in alphabetical order. So, our big story would be:
If I’m stripping this down to the simplest story, it might be:
Other stories can continue to build on this, but they would be deferred until the first simple iteration is completed. Future stories could be:
This is not overly complex, but as you layer on more pieces, the more complex it becomes. Once I have all the necessary basic information, I would start thinking about how my users might want to manipulate the data – sorting, filtering, favorites, etc. That starts moving us into the complex realm, but we started with the most basic stuff first, so it’s easy to build upon.
Questions to Ask:
- What is the absolute simplest version of the solution that we could build?
- Are there logical chunks of data that can be split out to start with, to be added later?
- What is “enough” to get useful feedback from users?
Again, it’s much easier to start with a simple concept and build on it than to try to architect a solution all up front (which isn’t very agile, anyway). As the original agile proponents stated, the best designs will emerge – this is a great way to let that happen organically.