There Should be Tracer Bullets in Each Sprint

Table of contents
Reading Time: 3 minutes

Tracer Bullets, as the name implies helps you trace the trajectory and the position where they hit the target. They are just like the regular bullets except that they have a modified base to contain pyrotechnic charge. This composition burns brightly when fired and allows the shooter to view the projectile. A machine gun usually has one tracer bullet for every 4-5 normal bullets which allow the user to take a better aim at the target. It helps the shooter understand where rest of the bullets are landing. In a nutshell it provides instant feedback and helps to aim right. Thus following the philosophy of Ready, fire, aim.

So how does it apply to the software that we develop? Well, if you notice closely then Agile helps us follow this in a way in which we are showing some constant work and soliciting feedback every few days. Until we show something working the stakeholders are not better equipped to take decisions. Assume that the stakeholders want to build a solution to market the big integration that the product is supposed to do with the market leader CRM solution. They would have some ideas but those might not be concrete enough. There are a few ways of demonstrating how the user story would work.

  1. Spike – a spike is a quick and dirty implementation to show that the suggested solution would work. It does not follow the laid down architecture and might be done in a different language all together. For example a spike could be done in RoR and then later implemented in Java. These are more like prototypes and are thrown away.
  2. Research – this has a larger base and might be very theoretical. Research should be time boxed and the results should be good enough to indicate whether a spike or a tracer bullet is required or may be the team needs a different direction all together.
  3. Tracer Bullet – the tracer bullet is a spike with the current architecture, current technology set, current set of best practices which results in production quality code. It might just be a very narrow implementation of the functionality but is not throw away code. It is of production quality and rest of the iterations can build on this code.

If you are following Agile, I would recommend the tracer bullet approach because you get the benefits of doing a spike and that too which results in production quality code. It would be a narrow implementation of the functionality but would have all the ingredients of the current technology stack. You would be able to gather stakeholder feedback. You do not need to throw away this code and can build on that.

I remember working together with a few esteemed architects who built the E*Trade platform. When we were about to start the project, they mentioned that let us build a “count service”. I am assuming that you would be as lost as I was on what the hell this count service is. People who have worked on the E*Trade platform would be able to relate to this. As it turned out, the count service was a tracer bullet. It was a service that did nothing more than incrementing a counter in the database, however, it was production quality. It made its way through all the layers and came back with the incremented counter. All the code quality specifications were adhered to and the unit tests worked like a charm.

The count service was a production quality code which other developers used to reference and extend.
Hence every sprint should have a scope for tracer bullets. There is a fair chance that stakeholders have some idea about user stories but would like to see something working before they can take decisions. If this is the case then before venturing out by building the entire story, build tracer bullets.

There still might be a need for spikes and lengthy researches for a product but if you want the biggest bang for your buck then get your tracer bullets ready. Which way would you generally like to go with your Agile sprint, spikes or tracer bullets?

Written by 

Vikas is the CEO and Co-Founder of Knoldus Inc. Knoldus does niche Reactive and Big Data product development on Scala, Spark, and Functional Java. Knoldus has a strong focus on software craftsmanship which ensures high-quality software development. It partners with the best in the industry like Lightbend (Scala Ecosystem), Databricks (Spark Ecosystem), Confluent (Kafka) and Datastax (Cassandra). Vikas has been working in the cutting edge tech industry for 20+ years. He was an ardent fan of Java with multiple high load enterprise systems to boast of till he met Scala. His current passions include utilizing the power of Scala, Akka and Play to make Reactive and Big Data systems for niche startups and enterprises who would like to change the way software is developed. To know more, send a mail to or visit