IIBA IIBA-AAC – Techniques on delivery horizon Part 3

4. Spikes

Sometimes you know that you don’t know something, but you still want to capture it in your backlog. This is when spikes come to rescue. Just like stories. Spikes are an invention of extreme programming XP. Originally there were special types of backlog items that are used to gain the knowledge necessary to reduce the risk of a technical approach or to better understand the requirements or to improve increase the reliability of your story estimate. Due to the nature of exploration needed to complete a spike, we can distinguish three different types of spikes. The first one is called functional. Spike. Its goal is to analyze the story and determine how to break it down into smaller stories of tasks or to identify where risks and complexity exists in your stories. Another type of spikes is technical.

Technical spikes determine visibility or impact of a story or task, ultimately helping to land on a technical design for the solution for a particular story. And the third one exploratory spike. This one explores organizational risks or impacts for a particular initiative or backlog items, basically performing the organizational analysis whether your enterprise is ready for this story to be delivered or some other organizational changes are needed, regardless of the type of dispute that you are using. These pipes are typically created after you have a story in your backlog. So you first create a story, then the team looks in the story and they may ask questions or may have concerns about it. So you suggest how about we don’t deliver the story yet, but create a spike to analyze it further or explore the domain around it so we are more confident in delivering it. Here is a nice spike template that I use in my work and I want to share it with you. We start with defining this spike’s goal.

What do we want to achieve and why this spike exists in the first place? This is something that gets recorded under the goal. Then we give our spike a timebox. A timebox is time frame that you are allowed to spend on this spike. When the time box is exhausted, you are forced to stop your research even if you haven’t finished it. So if you manage to finish this bike before the time box is exhausted, that is great. You saved the team some time, but if you didn’t, it means when the time box comes, you need to stop your work and reassess what you get. Typically it means you realign with your team and you look at what you’ve learned and decide if any further exploration is needed. Or we already have enough information to make a decision, we just haven’t noticed it.

The next one is considerations. What are the things that you need to take into account when performing this bike? Some things that you may forget about, so you write them down, not to. Then you list your showstoppers. This is the information that when becomes available means you need to stop your research straight away, there is no need to continue it, or you’ve learned enough to make a decision that this is not needed. Sometimes showstoppers are the fact that this solution is not technically possible. If you learn it at any moment in time, there is no need in continuing your research. If it is not technically possible, let’s forget about it and start researching for a different solution. Expected Results these are the things that you are expected to produce as a part of your spike. Typically these are the documented results of your research, some proof of concept and things like that.

Now let’s have a look at a small example of how a spike may work. Let’s imagine we have this user story as a customer who receives SMS bills, I want to see the due date and payment amount in the SMS so that I know when and how much to pay. You may have this user story in your backlog and you may take it into the elaboration session with your stakeholders. And one of them, most likely developer, may ask a question like this but can we even theoretically get this data to include it in the SMS? So in your infrastructure you may have your bill related data living in one system and you may have another system sending the SMS messages. And reasonable question is can you access the data from the billing system, from the SMS system, so that you can pull this data and insert it into your SMS to actually send it to the customers? Very reasonable question, isn’t it? And if you don’t have an immediate answer to this question, you may suggest to have a spike.

So let’s have a look at how this spike may look like. We start with our law. The goal for this bike is to learn how to retrieve the data and make it available for SMS sending system. You write it down as the first paragraph of your template. This bike’s goal. Then, together with the team, you decide how much time do we want to spend on this thing? Or can we spend on this thing without sacrificing the rest of the timelines? Let’s say we decide on two days of investigation for a single person to dirt. Then you list all the considerations and the key consideration here is this is a sensitive data, so the connection needs to be secured. Then you list the showstoppers you need to stop investigation should you realize that data is not accessible. If you cannot get the data, you stop the spy gaske collected to the team and you decide what you do next. Finally, what is your expected result? In this case, it is a POC for integration. You need to show and prove that you can get the data and make it available for another system.

This PSC is not a production ready solution, but it should be functioning enough to show that this solution can be built based on the results of this proof of concept. So this is how you use Spikes on the project. You start with analyzing this story. You realize there are some questions that you cannot answer immediately, and you need to spend more time finding supporting evidence to make a decision. And then you record a spike. You document it following a template, and you give it to one of your team members to resolve. Spikes can be a great addition to your backlog management toolset because the combination of specific activities and time box provides focus for the team to get the clarity that they need. It also gives permission to spend time on value driven research.

And when used early in information, it helps team members build and share knowledge about each other and the technology to be used for the solution. Spikes do have some limitations. They can be too long a timebox or too large an item to have clear objective and outcomes outcome. In this case, you will need to find ways to break it down. The term can be used incorrectly, and sometimes it can be used to reference some follow up conversations or other activities, meaning that the stories are not done or are not elaborated upon correctly. If Spikes are used too frequently, this means the product backlog refinement is not meeting.