tt100 (Time to 100) is the amount of time it takes an engineer to write 100 lines of code and a way to assess how quickly the codebase is being meaningfully edited.
In this article
Which reports use tt100?
See tt100 Raw and tt100 Productive in Trends.
How is tt100 calculated?
Flow looks at:
- how much of the code is not removed or modified within 30 days, while screening out noise like someone adding a large library
- how many days each developer was actively coding. We look at when people are actually coding and only take into account those spans of time so that days spent planning or holidays don't affect the calculation.
Flow assumes eight hours per day.
These inputs are used to approximate how long it takes for 100 lines of code to be reached. tt100 Raw includes reworked code. tt100 Productive excludes reworked code.
What does tt100 measure?
tt100 is a measurement of how long it takes an engineer to write 100 lines of code. This is a way to measure velocity based on how quickly code is being produced (as opposed to something less concrete like tickets). But hang on. We all know mere effort is not the same as forward progress—which is why we use two different forms:
- tt100 Raw: The amount of time required to create 100 lines of any type of code, regardless of quality.
- tt100 Productive: Time required to create 100 lines of code, minus rework. In other words, forward progress.
Let’s look at an example of how this works. This example graphic shows example tt100 statistics for an engineer, who we’ll call Tom:
Looking at these metrics, we see a couple things:
- Tom’s tt100 Raw is trending down over time. He’s writing more code, faster, when measured in an absolute sense. In January it took him over two hours to write 100 lines of code, and by June he cut that in half to about one hour.
- However, Tom’s tt100 Productive is drifting in the wrong direction. Even though it takes him less time to write raw code, it used to take Tom about three hours to produce 100 productive lines, but now it’s taking him almost twice as long to reach those same 100 productive lines.
The difference between these two tt100 metrics is important: it’s a sign that Tom is checking in a lot of work, but actually is struggling a bit compared to before. Knowing this, the team lead should intervene before this snowballs out of control. Together, they can discuss how to get things back on track.
Common culprits for this kind of shift include both engineering and non-engineering factors:
- Dead-end implementation paths
- Poor or shifting product requirements
- Lots of requested edits during code review
In the example shown above, let's say this was the result of ill-defined requirements: Tom is working really hard, but a trial-and-error approach to defining feature requirements isn’t serving anyone. Knowing how much work is being wasted here, Tom and the team lead can now meet with the product owner and find out whether these late-term adjustments are worth the extra expense and delayed delivery.
Historically, these kinds of conversations are difficult to have in absence of concrete data. With tt100 metrics, this becomes more tactical: “The constant spec changes are causing this work to take 1.8 times longer than it normally does to deliver. We need to work toward clearer targets, or be comfortable with some significant delays.”