20/80 Rule Reloaded

Table of Contents

The 20/80 Rule Reloaded

A short thought occurred to me.

Many people know and possibly apply the 20/80 rule (the whole Agile framework is based on it!), which, when generalized, goes something like this: “20% of our actions generate 80% of the results.” In other words - “roughly 20% of what we do makes sense.” It’s a strong statement, isn’t it? Simple?

Incredibly difficult! Because we are accustomed and conditioned to fill our time - to have the feeling that we are always doing something.

But that’s not what I wanted to write about. I wanted to point out that many people (I don’t want to use the word “majority,” though I wouldn’t be wrong by much) incorrectly interpret this statement.

It does not mean that once we reach 80%, we shouldn’t put any more energy into further work (project, release, functionality, task, whatever)… in fact, by then it’s too late! We would have already wasted a tremendous amount of our precious time. Because what good is 80% if it’s just crap, a cotton candy of tasks or functionalities?

The above principle means: find the 20% worth focusing on and, once you find it, put 200% energy and commitment into it. The rest can be dismissed, preferably by renegotiating the completion of “the rest.”

Business-wise: instead of creating a large system with 100 features, it is better to ask yourself what will really be useful and what will be used, and create those 20 features.

P.S.

In Domain-Driven Design (DDD), we call it the Core Domain! Always be aware of what your core is! :) Always ask yourself what is the Core in the system, module, or even functionality that you are working on.

(Text translated and moved from original old blog automatically by AI. May contain inaccuracies.)

Related Posts

Clients Want to Be Agile...

Clients Want to Be Agile…

One of the recent meetings involved establishing (by me, MS) a way to collaborate with a client (details intentionally slightly modified or omitted, though based on a real case). The client (K) said:

Read More
Antipattern: Adrenaline Junkie

Antipattern: Adrenaline Junkie

Understanding Project Pressure and Tension

I constantly wonder why situations arise where pressure and tension are generated in projects. One reason is that most projects are simply complex—you have to coordinate several, sometimes dozens of people, anticipate and plan in advance what will happen, and determine what resources will be needed. As a species, we’re not very good at detailed long-term planning (see: David Rock – Your Brain at Work).

Read More

The Natural Order of Refactoring Examined Part 4: Refactoring to Patterns

The Natural Order of Refactoring Examined Part 4: Refactoring to Patterns

By following the steps outlined previously, we begin to see a more structured solution, predominantly consisting of methods grouped into classes. It’s now time to apply object-oriented principles, such as those encapsulated by the SOLID principles. We analyze the code for patterns of repetition, the need for flexibility, and code smells, and introduce design patterns where appropriate.

Read More