Are you sure you want to spike that?

I have recently had some conversations about when it is appropriate to create a spike in Scrum. Is it when a team doesn't know how to approach a story? When they don't know how to utilize a tool or resource? When they have a question that they want to answer? Something else? I thought this would be a good time to dig into what a spike is, and what it isn't.

The term spike comes from XP (Kent Beck's Extreme Programming) (Spike | The Agile Dictionary).  A spike, paraphrasing Ward Cunningham, should be a story that can convince the team that they are (or aren’t) on the right track.  

One of the primary use cases of a spike is to help a team when they have a story that they are unable to estimate its size. Some stories are initially inestimable because there are questions that need to be resolved first. For example, the team may not know if a technology is appropriate; will it handle the expected load? In this case the team should create a spike. Inversely, if the story can be estimated then the team should not create a spike.

Experimentation and learning are key elements of a spike. Too often I see a team creating a spike during refinement, or earlier, for understanding how to use a technology that is new to the team. They create the spike before they know if they are unable to estimate stories.

So now that we know when to create a spike, let's take a look at the components of a properly formed spike. A well-formed spike will have these three elements:

  1. Understanding Needed Information
  2. Acceptance Criteria
  3. Timeboxes
Let's discuss each one of these.

Understanding Needed Information

The team members need to all understand and agree on what they need to determine to be able to estimate the inestimable story. This is the focus of the spike. This focus is essential to making sure we get the answers to the current questions. When a team doesn't focus on what is needed and casts a wide net, they inevitably end up wandering in their search for information. When creating a spike, the team must know what the focus is.

Acceptance Criteria

The acceptance criteria of a spike should not be "we now know ____". The spike is done when we know enough to estimate the story that before could not be estimated. So, the acceptance criteria should be "we are able to point story NNN" or better yet "we have assigned story points to story NNN". The output of a spike is the team's ability to move forward with some confidence that they are on the right track. 

Timeboxes

It is a good idea to assign an initial timebox to a spike. This is the amount of time the team will work to answer "The question" before they come back together to determine if they have an answer or need to allocate an additional timebox.

The reason for managing the spike with timeboxes is that it ensures that the team keeps coming back together to share with each other what they have learned and to check if they have their answer. It can be the case that individually they don't have the answer, but collectively they do. Additionally, each timebox that is allocated also may have a focus for the timebox if the question that needs to be answered is a large one.

Wrap-Up

Hopefully you now have a good sense of when to create a spike and how to create a well-formed one. I'd love to hear your feedback.

Stay Agile.

Comments

Post a Comment

Popular posts from this blog

The Five Dysfunctions and Tuckman's Stages

No, this is not a post about a new band, it is about understand Scrum team growth . In my  previous post I discussed The Five Dysfunctions of a Team by Patrick Lencioni and how the dysfunctions in that book apply not only to management teams as described in the book but to Scrum teams as well. In 1965 Bruce Tuckman proposed his model of team development. While you may not be familiar with Tuckman’s name, you have probably heard of the stages of his model, forming, storming, norming and performing. Forming - The team is coming together for the first time. Team members behave independently, they are on their best behavior and very focused on themselves. To move out of this stage, team members must be willing to risk the possibility of conflict Storming - The team members are learning each others strengths and weaknesses and learning to trust each other. Some of the teams disagreements are passionate, but also can tend to lean toward personal attacks as opposed to healthy confl
Read more

How many dysfunctions does your Scrum team exhibit?

Image
If you say your team does not exhibit any dysfunctions I have to ask you to revisit your thoughts again as that is so very highly unlikely. Most if not all teams exhibit some dysfunction some of the time, if not all of the time.  Merriam Webster defines dysfunction as  impaired or abnormal functioning or abnormal or unhealthy interpersonal behavior or interaction within a group I think both of those definitions work well with regards to a Scrum team. In Patrick Lencioni's book The Five Dysfunctions of a Team he tells a tale about the five dysfunctions that a team typically struggles with followed by a discussion of how to address them. As a scrum master it is well worth the time to read it. As far as I know the author was focusing on management teams when he wrote it, but without very much tweaking, all the same dysfunctions and corrective actions apply to a Scrum team as well.  The five dysfunctions are laid out in a pyramid. The reason for the pyramid is that
Read more

Feedback - Skills Relevant in the Torah and Today

There is a story in the Old Testament known as the Waters of Strife . It occurs when the Jews were wandering in the desert. They complain to Moses that there was no water and that they were going to die. Moses prays to G-d, the response is to talk to a rock and tell it to give water. Instead of talking to the rock, Moses hits the rock and water comes out. Aaron was punished after this incident. Reading the text in the original Hebrew, Aaron wasn't given any instructions other than to accompany Moses, which he did. What did Aaron do wrong? Why was he punished? At this point if you are still with me, you are probably wondering what this has to do with agility or Scrum. It was Rabbi Yehuda Meyers that gave me the answer to both of those questions, both what Aaron did wrong and what does this have to do with Scrum. Aaron's mistake was a simple and a common one, unfortunately one made on many Scrum teams.  First, a bit of background is needed. This event occurs right after Mo
Read more