I have been involved in a lot software projects in my professional life. And no matter the organization there has always been two constants: pressure from “the business” to increase the scope, and some sort of deadline (tradeshow, quarterly goal, etc.) that “management” won’t bend on. Everyone knows you can’t have your cake and eat it too though and I’ll show you why, with what I humbly, call “Ellis’ Law of Software Projects”.

Ellis’ law is simply this: (Scope * Quality) / Resources = Duration. This ‘law’ isn’t something I have decreed to be true in projects I’ve been a part of. It is something I have observed; more like how Newton observed an apple falling on his head. There is immutable relationship between each component of the equation. If you change one component, then at least one other will change. Let me break this down further by sharing my definitions of each component.

Components of the law

Scope is simply the list of stuff to be built. It could be a marketing requirements document (MRD), a product requirements document (PRD), a Scrum product backlog, a BDD behavioral spec, or any other form of ‘requirements’ even if it’s just a list in the founder’s head.

Quality in this equation is expressed as an oversimplified 0-100% of the theoretical quality you could intend to achieve for a project. QA is always the first place people, especially management, want to trim when a project timeline gets tight. They never explicitly accept that they are allowing the quality to drop of course. In their mind the quality should stay the same; we usually do a lot of superfluous tests apparently. But even if you are comfortable with the resulting quality of the project, you will never be as certain the quality is as high as you would like.

Resources has a very broad meaning in this context. It represents anything that can be used to complete the project. It can be more team members, longer hours, improving the talent level of the team, faster computers, more monitors, you can even increase the resources by lowering the overhead (meetings, process, etc.) that takes up the team’s time. Once QA has been trimmed to the bone, the next step is always stealing resources from another team even though your team wastes 1/3^rd of their time in meetings.

Lastly, the result of all of this is the duration of the project, which is pretty self-explanatory. In the primary form of the equation expressed above it is how long the project will take. It can also be the duration you desire if you are solving for one of the other components though.

Permutations of the law

You don’t need to exactly calculate the law but I like the equation form of this idea. Using basic algebra concepts you can ‘solve’ for each of the different components. If you know your scope, quality, and resources then the duration is decided for you.

If you know your scope, quality, and how long the duration can be then you know what kind of resources you will need to complete it on time.

If you know your scope, duration, and resources then you know what quality you will end up with.

If you know your duration, resources, and quality target then you know how large your scope can be.

tl;dr

So next time someone says you need to ‘accelerate’ some project because it has to be done sooner you know what you need to do. You need to figure out a nice way to either 1) ask for more resources, 2) ask them which features they want to drop, or 3) explain to them why you are lowering the quality bar. The choice is theirs.