• 80% of the sales are closed by 20% of the salespeople.
• 80% of the code on a project is written by 20% of the staff.
• 80% of the processor execution time is spent in 20% of the processor’s instructions.
• 80% of your customers use only 20% of your application features.
• 80% of your defects are in 20% of your code.

Erik Peterson presents on the 80:20 rule at a Google Talk, which you can view on YouTube.com.  He explains how to use the 80:20 rule to improve the quality of your testing with the benefit of delivering high quality software products.

History

The 80:20 rule was first demonstrated by Joseph Juran.  The 80:20 rule says that 80% of the effects come from 20% of the causes.  It’s an indicative trend supported by observation and experimentation.

The principal was coined by Joseph Juran, a management consultant notedfor his focus on quality.  He named it after an Italian Economist, Vilfredo Pareto who observed that 80% of the wealth in Italy was owned 20% of the population.

IBM was able to use this insight with great effect when they found that 80% of the execution time was spent in 20% of the instructions.  With this information IBM optimized those 20% instructions giving them a competitive performance edge.  Apparently IBM treated this as a closely guarded secret.

What exactly is it?

Mr. Peterson explains that in Cricket the sweet spot on the bat is where the minimum effort maximizes return.  It’s that small area, the 20% area, on the bat that will catapult the ball the furthest with minimal effort from the batter. It’s what makes professional athletes as they are able to connect the ball with that small area of the bat more often than the amateur.  Identifying the sweet spot, that small area on the bat, is what Pareto Analysis is all about.

Pareto Analysis is the study of the main causes/classifications of something to link them to the properties in the results.  The objective is to establish the relationship between causes and results.

7 step process

A graph is used to perform Pareto Analysis.  There are 7 steps performed in the analysis to identify the most important causes.

1. Build a table listing the causes and their frequency as a percentage.
2. Arrange the rows in the decreasing order of importance of the causes (i.e, the most important cause first).
3. Add a cumulative percentage column to the table
4. Plot with causes on the x-axis and cumulative percentage on y-axis.
5. Join the above points to form a curve.
6. Plot (on the same graph) a bar graph with causes on the x-axis and percent frequency on the y-axis.
7. Draw line at 80% on y-axis parallel to x-axis. Then drop the line at the point of intersection with the curve on x-axis. This point on the x-axis separates the important causes (on the left) and trivial causes (on the right)

Example Behavior

How many Peanut characters did Charles Schulz introduce into his Peanuts cartoons? A survey was conducted where people where asked to name their favorite Peanut character.  The results of the survey unsurprisingly followed the classic 80:20 rule where 80% of the total favorite votes were for 20% of the characters: Snoopy, Charlie Brown, and Linus.  The answer to the beginning question is that there were 54 named characters in the cartoons.

Agile and the 80:20 Rule

Conceptually the Agile paradigm is based on the 80:20 where the objective is to deliver the most important features first. If those features are identified well, it is likely that only a small percentage of the universe of features will satisfy 80% of your customers.

I plan to discuss more about the Agile relationship in a future posting.

Testing and the 80:20 Rule

In 1976 Glenford Myers recommended writing test cases before you execute them, and he observed that defects cluster.   Based on this observation, he recommended pausing what you are doing and writing more tests for where you are finding bug clusters.  In addition he found the following:

• 80% of the defects come from 20% of the modules.
• 50% of the modules are defect free at system test.
• 10% of the modules are responsible for 90% of the system downtime.

Implications

1. Defects are where you are finding them. If you are finding defects in an area, there are more there.
2. Detailed tests are not required for all functionality.
3. Sweet spots are where a majority of the defects are. Find the sweet spots, develop more tests in those areas, and test them more.
4. 10% of the modules are responsible for 90% of system downtime.

As Beck would recommend, look for code smells.  Bugs are where you smell them.

How to Find Code Smells?

Unfortunately, you won’t find the Pareto relationships until you start testing.  It’s essentially a feedback loop, but there are ways to be proactive:

• Identify features/functionality by risk and develop more tests there.
• Concentrate your testing on new features or complicated areas.

As any QA professional knows, often developers aren’t very helpful with identifying these areas.  Erik recommends looking at the checkout records.  Where there are more checkouts, the risk of defects is likely higher.

Alternatively, focus on the areas the customers use most of the time and make them really usable.  Most defects will go unnoticed by customers where the user experience is superior.

Prioritize on Feature Use

Test where the users spend most of their time.  Microsoft apparently uses approach to deliver their products, and in my experience with great effect (see Microsoft’s CEO: 80-20 Rule Applies to Bugs, Not Just Features).   I rarely experience a defect in Microsoft’s desktop applications; the operating system is another story, however.

I would sometimes wonder how Microsoft could deliver such high quality in their office products.   In hindsight it’s quite obvious how they achieve it.  I suspect that I’m like most Office users; I use 5% of the functionality 98% of the time.

If they get that 5% correct, most customers rarely experience a defect.  Interestingly, when I think of the times where I did notice a defect in the Office products, it is when I use a tangential feature like mail merge in Word.

Summary

The 80-20 rule, when applied to testing, can have great effect on your quality and user experience.  In product delivery environments where there is constant pressure to deliver faster, applying the 80-20 rule helps to prioritize your efforts and makes it possible to deliver faster while satisfying a majority of your customers.  While our culture has embraced faster is always better, this is one tool to help identify your priorities with improved product success.

Watch the presentation.  It’s very good.

Mary Poppendieck speaks at a Google TechTalk on the role of leadership in software development. She presents an interesting history on the philosophy of management and how it has morphed over the years to its present day practices and theory.   Mary Poppendieck is the author of Lean Software Development: An Agile Toolkit (The Agile Software Development Series) and Implementing Lean Software Development: From Concept to Cash (The Addison-Wesley Signature Series).  She describes her Lean manufacturing experiences at 3M and how they relate to Agile Software development.