Famed marketing expert Jay Abraham has said that there are only three ways to grow a business. In laying out the formula, he points out that you can double the size of your revenue by slightly increasing each of the three variables.

This got me wondering if there is a similar, simple way to model the time it takes to build a technical product. After doing a bit of math and playing with equations, I think the answer is yes.

I’ll be writing some more practical posts that make use of this information in the near future, but for now, we’ll just look at the math.

*Warning: Math ahead.*

If you remember your high school physics equations, you know that an object’s average velocity is the total distance it has traveled divided by the total time it has been traveling.

**v = d / t**

If we know the distance traveled and velocity and want to know how much time it has taken, we can just do a bit of basic algebra and get:

**t = d / v**

For our purposes, let’s suppose the following:

- t = total development time
- d = total number of features needed
- v = development velocity

Development velocity could be described in a number of ways, but let’s just say that it’s the average number of features the development team completes per week.

So, if we need to develop 20 features, and the team completes 2 features per week on average, it’s going to take 10 weeks.

Simple.

But what exactly is “developer velocity” made up of?

To break it down, we need to look at what things impact how fast the development team moves on any given feature. I hypothesize that velocity can be mostly – if not entirely – described by three variables:

- Feature complexity
- Developer skill
- Developer focus

How do each of these things impact velocity?

- As feature complexity goes up, velocity will go down.
- As developer skill goes up, velocity will go up.
- As developer focus goes up, velocity will go up.

This implies a relationship that looks something like this:

**velocity = (skill * focus) / complexity**

*Aside: It’s possible that you might want to use “difficulty” as a somewhat broader concept than complexity, but I’m going to leave it as is for now.*

For this formula to make any sense, we need something that has the same units that we used to describe **velocity** when we defined it above: *features per week*.

Teams often define complexity in iteration planning meetings with a number of points per feature. So let’s just say that complexity has units of *points per feature*. That means that our *skill * focus* expression needs to have units of *points per week* in order for this to work out right. Our unit conversion looks like:

**velocity = (skill * focus) / complexity **

**=> units: (points / week) / (points / feature) = (points / week) * (feature / points) **

**= features / week # the points cancel**

Perfect.

We are making an assumption on the multiplicative relationship between skill and focus. I admit that, and I’m not totally sure how to effectively tease that apart.

One way might be to model skill as a maximum number of points possible per week and then look at focus as a percentage. So if I’m a developer capable of 15 points per week, but I didn’t sleep much and I keep getting dragged into meetings, my focus might only be 60%. So – I’m only able to do 9 points.

Plugging this back into our original equation and simplifying the fraction, we get:

**development time = (number of features * complexity) / (skill * focus)**

Awesome.

There’s one more final point of clarification I think we can make.

**Feature complexity** can potentially be seen as fixed since a feature is a predefined solution to a particular problem. However, problems often have many solutions – some of them much less complicated than others.

We can broaden this out to be **solution complexity** to highlight the fact that complexity is often changeable. That gives us:

**development time = (number of problems * average solution complexity) / (skill * focus)**

Now that we’ve got this, what happens if we improve each variable by 10% – i.e. reduce the numbers on top and increase the numbers on the bottom?

**development time = (0.9 * 0.9) / (1.1 * 1.1) = 0.67**

In other words, by improving each variable by just 10%, we can get the job done in 2/3 the time.

If we do 15%:

**development time = (0.85 * 0.85) / (1.15 * 1.15) = 0.51**

…or about half.

An important consideration at this point is whether or not you can actually quantify and measure these things. I’m not entirely sure at this point, and even if you can, I’m not convinced that it’s helpful. What does seem helpful to me is to consider the mechanics at play.

As I said earlier, I’m going to use this write-up as the basis for future, in-depth posts about improving team performance. But for now, here are a few high level takeaways:

- Every company should be investing seriously in developer training.
- Every company should be making sure that their teams have the ability to focus (healthy environment, not too many distractions / meetings, etc.).
- Feature lists should be heavily scrutinized and kept to what is essential.
- Features should be evaluated to find the least complicated way to solve each problem.

**Need Help?**

We are a full service software engineering firm. We can help you with everything from design to project management to development.

Got a project you’d like to talk about? Get in touch at info@centralstandard.tech.