There are two terms we’ve often seen used interchangeably that I would like to address today. These are Development Time and Time to Market. These terms embody the concept of time taken to get a feature to the end user.
While some would argue that the distinction is moot, I would argue that it is very important and worth taking the time to write about because it helps to:
- improve communication
- manage expectations
- become more efficient
Let’s start with some definitions. I might lapse into Scrum speak, but the idea is not limited to the Scrum framework and should apply everywhere.
Development Time
I define development time as the time between when a developer accepts requirements and the Product Owner accepts the feature. Development time includes the actual time spent on coding, code reviews and Quality Assurance. This time does not include things that are done outside of development, such as the overheads involved in feature definition, effort estimations etc.
I would also argue that it shouldn’t include time taken for DevOps as that should stand on its own. Thus, developers can and should consider the feature (and development time) finished once the feature is accepted.
Time To Market
Time to market on the other hand, is the time taken from the idea to the finished feature. This includes the pitch, requirements gathering, feature definitions, development, testing, deployment… basically everything that has to happen to get the feature into the hands of end users.
In the image the light green area represents time to market, and the light red represents development time.
Another important aspect of time to market is that it also includes any time spent waiting. Since a picture is worth a thousand words, so here’s an infographic and an overly simplified example:
Let’s assume a software product is released every month on the 30th, and a new feature is proposed on the 1st.
Also suppose:
- it takes a week to do all pre-development tasks (1st to the 7th)
- a week for the actual development (7th to the 14th)
- another week for any pre-release tasks, like release testing (14th to 21st)
While the development time is only one week in this example, the time to market will be a month, because of all the steps necessary before and after the development, including waiting for the next release window.
Obligatory Elephants to Address
At this juncture, I’d like to take a moment to address the two elephants in the room:
1. Does a feature have to wait for a release date?
Can’t it just go live when it’s ready? Short answer: it can, but that’s out of scope of this post. That would be a longer discussion about benefits and costs of a CI/CD pipeline, so we’ll skip it for now. However, if you are interested in more advice and support on designing a lean developer friendly CI/CD pipeline, feel free to reach out to us djangsters, don’t let the German intimidate you, we also speak English.
2. Relationship between Development time and Time to Market
The scenario given above is not the only one. It is just an easy way to differentiate time to market and development time.
Depending on the project, development time could be smaller, equal to or even greater than time to market. For example in a web development scenario, development time can be smaller than time to market. On the other hand games often take years of development and continue even after they are in the hands of users. Here, the development time is larger than the time to market.
Why is this distinction important?
It improves communication and helps manage expectations
It’s a fact of life that developers and stakeholders speak different languages that often use the same words to refer to different things. If both developers and stakeholders know the distinction then misunderstandings are less likely to occur.
It focuses optimization efforts
When we talk about process optimisation we often only consider improving development time. I think this is unfair as you could have the best developers in the world, but if it takes a feature 3 months to pass through requirements and get into the hands of those developers then the time to market will always be outrageously long. It won’t matter if the rockstar developers can build Rome in a day.
In Conclusion
Software development is a challenging yet rewarding endeavor, which involves many people from different backgrounds. Differentiating between time to market and development time goes a long way towards improving everyone’s experience. It allows us to identify improvement opportunities and tailor the process to the project’s needs.
