A couple of years ago, a team that I was working on as ScrumMaster had a discussion on what is a spike versus research versus tracer bullets. The reason for the discussion was how loosely we used these terms with our current customer. It was confusing to both the customer and us. It also allowed too much room for working on things we did not commit to as a team within a Scrum sprint.
The team sat down and decided that spike, research, and tracer bullet all meant different things to them. Here is what we decided on along with their respective indicators for using them:
- Spike – a quick and dirty implementation, designed to be thrown away, to gain knowledge – indicator: unable to estimate a user story effectively
- Research – broad, foundational knowledge-gaining to decide what to spike or give the ability to estimate – indicator: don’t know a potential solution
- Tracer Bullet – very narrow implementation in production quality of an epic/large user story – indicator: user story is too large in estimation
This clarification allowed the customer and team to identify when and how these activities should be used. We decided with the customer that a spike and research were timeboxed activities and were similar to an investment by the customer. These were done in one iteration and used to help define an upcoming user story’s estimate and a starting point for implementation in the next iteration. Although estimates were an indicator for spikes and research, they were not the end goal. The idea of a spike or research is also to:
- Understand “how” to implement a piece of business value
- Propose a solution to help the customer make business value decisions
- Minimize risk hidden in the cost of implementing a piece of business value
- Control the cost of R&D through the use of an “investment” model
A tracer bullet was used to breakdown an epic or large user story into smaller chunks and could have some effect on the customer’s backlog of features. If the team discussed a user story on the backlog which introduced a new architectural element then a tracer bullet would be implemented to introduce it into the software without the overhead of a detailed user interface. For instance, if we were hooking into our Peoplesoft and Siebel instances and wanted to show a customer’s information combined from both systems, we may have a tracer bullet user story such as:
As a customer service rep I want to view the customer’s name and multiple system identifiers
After implementing this user story we may have many other backlog user stories which references additional customer information which must retrieved from either or both of the systems.
The team put these definitions and indicators up on the wall as a big, beautiful information radiator that we could refer to. Other teams also started to use these descriptions in their own projects to help clarify essential work with their customers.