How to apply the Pareto principle!

It all started in Italy when Vilfredo Pareto observed that approximately 80% of the land in Italy was owned by 20% of the population. He came up with a principle popularly known as the 80–20 principle that states roughly 80% of consequences come from 20% of causes.

The majority of results (80%) come from the minority of causes (20%).

Various industries have their own interpretations of this rule:

• In business, 20% of input results in 80% of output.
• In sales, 20% of clients give 80% of sales.

This principle shows the imbalance between the input and output between effort and result.

We are going to discuss how the 80–20 rule can be applied to the various aspect of Software development in this article.

Standish Group “Chaos” Report 2002

The general rule of the thumb is “20% of the features are used by 80% of the users”. This report goes beyond this statement and digs deeper.

The Standish Group “Chaos” Report 2002 brings out the usage of software features:

• 7% of features are used always.
• 13% used often.
• 16% sometimes.
• 19% rarely used
• 45% of features are never used.

This shows how the teams waste a lot of time developing the features that users don’t need/want. Most of the product managers know this rule, but still, they make this mistake. Analytics is not given enough importance that causes the product development drift from its main use-cases.

MVP

Minimal Viable Product is the concept that most of us get wrong. I have seen many product managers who want to add a lot to features in the MVP itself.

MVP should be solving the most important use-cases and solve them well.

Most of the major problems (~80%) should be addressed in MVP (~20%).

As the Pareto principle says the majority of results come from the minority of causes, MVP is the cause that covers 80% of the use-cases.

UI/UX

20% of the views are 80% of the most used use-cases.

The rule that applies to MVP applies here as well. Most of the views that developers work on and spend a lot of time on are not visited or visited rarely by the users.

Creating a good UI and UX might give you a kick but most importantly the primary question you need to ask is “Does this view fall in the path of the main use-case?”.

In development

80% of the most widely used features are developed with 20% effort (lines of code)

Since I have been a developer, I can vouch for this. Since I have been a developer, I can vouch for this. I have spent most of the time (80%) on trivial tasks. All the add-on features, corner cases, bugs due to these corner cases, and many such tasks take most of the time to develop but don’t fall under the most widely used features.

QA

The measure of QA’s performance is judged by the number of issues/bugs he/she finds in a release. This is one of the illest practiced customs in the industry.

80% of the use-case has only 20% of bugs.

Most issues found by QA are in the 20% of the use-case that is rarely/never used. And developers spend their time fixing these issues that do not make much improvement.

An effective project manager can prioritize these bugs based on the impact on users’ experience and not on the impact on the feature. Keeping this in mind during the bug scrub can help correct the path of development.

Agile

The idea of agile methodology is to ship the product/features as soon as possible to get feedback and correct the course of execution accordingly. More often than not the team starts focusing on the features that are not part of the most widely used features.

The Pareto principle is true even in agile execution. During the journey, one wants to develop new features and then keeps improving these features without knowing the impact.

To avoid such scenarios, the analytics of usage of all features should be accessed at the beginning of each sprint.

Wrapping Up

In every aspect of Software development, the Pareto principle is true to a great extent.

The principle sounds like common sense. But I have never seen it in practice. I have tried to argue with Product managers and with the team members. I have succeeded only a few times.

Focusing on accepting the imbalance between effort and cause, prioritizing the tasks based on the impact they have, can help the team perform better and achieve more output. Sometimes, it’s required to step back and look at the bigger picture.