Research, Spikes, Tracer Bullets, Oh My!
Posted by Chris Sterling on 22 Oct 2007 at 04:27 am | Tagged as: Agile, Architecture, Product Owner, Scrum, TDD, XP
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.
So as I understand it, a “tracer bullet” is a reference implementation, yes?
I think they are quite similar with the caveat that reference implementations are usually created around a standard API whereas the tracer bullet is usually a thin implementation through all layers of the system. For instance, you may have a user story such as “As a customer service rep I want to view customer information”. This could be broken down into multiple stories since it may be too vague. A couple of these could be “As a customer service rep I want to view customer name and account ID”, “As a customer service rep I want to view customer’s address”, and “As a customer service rep I want to view customer’s account type”. These user stories could be done in any order but we may use one of them to prove the solution.
This comes in quite handy when you are pulling information from multiple back end sources such Peoplesoft, Siebel, and Oracle into a single reference of customer. We may want to see just the customer name and account number but on the back end make sure to hook all of the sources together for a global customer account ID. That would be a tracer bullet, in my opinion.
[…] is similar to spikes and tracer bullets in agile methodologies like Scrum. Except with tracer bullets you are working on a narrow […]
This is a great reference. Thanks a lot Chris.
Chris,
We’ve been discussing research stories as of late. Some contend that they should not have any points associated with them, while others contend that they should have points so that a team’s velocity is more consistent - especially if a team spends considerable time researching potential system changes for business value. What’s your take. Does it really matter if research stories have points or not as long as a given Scrum team stays consistent? Thanks … - Derek
Good day Derek,
I am fine with either way of calculating velocity as long as it is consistent for the team, as you said. I could go through a list of pros and cons for each but all that matters in the end is that the team’s choice is consistent.
Glad to hear you are using these to help drive out technical understandings.