I can’t recall when I first came upon the Pareto Principle. I think it might have been when I was studying for my Six Sigma Green Belt. But I’m unsure. I know I was operating as a QA Director at the time, because most of my example uses for it surrounded testing and defects. Nonetheless, it’s probably been over 15 years.

That being said, I don’t think I hear people “considering” Pareto enough in their day-to-day activity, so I thought I’d bring it up and remind everyone of the Pareto Principle or 80:20 Rule and it’s implications for software engineering in general and agile teams in particular.

Basics

In 1906, Italian economist Vilfredo Pareto created a mathematical formula to describe the unequal distribution of wealth in his country, observing that twenty percent of the people owned eighty percent of the wealth. In the late 1940s, Dr. Joseph M. Juran inaccurately attributed the 80/20 Rule to Pareto, calling it Pareto's Principle. While it may be misnamed, Pareto's Principle or Pareto's Law as it is sometimes called, can be a very effective tool to help you manage effectively.
Where It Came From
After Pareto made his observation and created his formula, many others observed similar phenomena in their own areas of expertise. Quality Management pioneer, Dr. Joseph Juran, working in the US in the 1930s and 40s recognized a universal principle he called the "vital few and trivial many" and reduced it to writing. In an early work, a lack of precision on Juran's part made it appear that he was applying Pareto's observations about economics to a broader body of work. The name Pareto's Principle stuck, probably because it sounded better than Juran's Principle.
As a result, Dr. Juran's observation of the "vital few and trivial many", the principle that 20 percent of something always are responsible for 80 percent of the results, became known as Pareto's Principle or the 80/20 Rule.
--Quoted from About.com

Implications

Let me give you a couple of scenarios that illustrate “80/20 in action”:

  • If you’re testing a software application, then 80% of the bugs will reside/surface from 20% of the applications components.
  • If you’re counting costs, then 80% of the cost of a Toyota Prius, will be contained in 20% of the component parts.
  • Continuing the Prius example, 80% of the weight, will be contained in 20% of the component parts as well. And if we’re putting them in storage, there will be a warehouse space equivalent.
  • Back to software, 80% of the technical complexity (perhaps call it risk as well) resides in 20% of an applications components.
  • And so on…

I really like Juran’s wording around “the vital few”. The 20% turns out to be the interesting case and, once we find it, we can adjust our views to handle it much differently than the 80%.

Disclaimer

Now of course the numbers aren’t quite that precise and I don’t want you to build your every action around or upon Pareto. But making it a part of your analysis and thinking has served me well for years in focusing towards what truly matters.

Agile Implications

Now let’s get around to some of the implications or examples within agile teams:

Backlogs & Product Ownership

  • 20% of the User Stories probably need some sort of “research spike” in order to sort through the technical implications and ambiguity.
  • 20% of the User Stories (functional work) probably contain 80% of the customer value. So find them and do those first.
  • 20% of the User Stories (non-functional work) probably need expanded Acceptance Criteria to better guide the confirmation of completeness.
  • 20% of the User Stories need to be groomed multiple times (discussed, broken down, estimated, explored) before they become “ready” for sprint-execution.
  • 20% of the Features drive probably 80% of the customer usage.
  • 20% of the Features will contain 80% of the stakeholder & customer driven change.

Technical Risk

  • 80% of the technical complexity is in 20% of the component work a team is taking on. Find it and handle it differently: designs and design reviews for example, teamwork and pairing.
  • The estimates for 20% of the more complex User Stories will be inaccurate or contain more variance. Consider this when estimating.
  • 20% of the backlog will have strong architectural implications.
  • 20% of the backlog will have cross-team technical dependencies.
  • 20% of the application will contain 80% of the technical debt. Or will be attractive targets for refactoring.
  • 20% of the application will require 80% of the maintenance activity.

Planning

  • 20% of the Release Plan will contain 80% of the risk.
  • 20% of a Sprint Plan (backlog) will contain 80% of the value, 80% of the risk, 80% of the swarming opportunity.
  • 20% of the Sprint Plan (backlog) will contain 80% of the testing activity, testing work, testing risk, bugs/rework.
  • 20% of the overall work will take up 80% of the time; I wonder if that has anything to do with “90% Done Syndrome”?
  • 20% of the teams work will result in 80% of the “blocking issues”.

Quality & Testing

  • 20% of the User Stories will contain 80% of the bugs.
  • 20% of the User Stories will contain 80% of the testing complexity and/or repeated testing risk.
  • 80% of the User Stories or Features need less testing than you might originally think—think risk-based testing here.
  • You’re test strategies and plans ought to include the 80/20 Rule.
  • 20% of the defect repairs will contain 80% of the defect rework.
  • 20% of your tests will take 80% of the time to run; find these and automate them…then go to the beach.

These were not intended as “exhaustive” lists. More so, they are intended to get you thinking of the implications of the Pareto Principle in your daily agile journey.

Wrapping Up

Now all of that being said, there IS a challenge in using the 80/20 Rule. Its finding the 20%! Because its not always evident where it is.

 

Let’s take the bug example. It clearly aligns with my experience that 80% of the bugs “cluster” around a small percentage of the code in every application I’ve ever tested. Let’s call that 20%. So from a testing strategy and planning perspective, 80% of my effort (testing hours) should be focused there. However, finding or predicting those defect clusters isn’t that easy. If I’m presumptuous and think that I can predict them all, then I will most likely have wasted some time and missed some critical areas. So blind use of Pareto isn’t in your best interest nor is it prudent.

However, you should constantly be thinking of Pareto sweet spots in your daily work. It aligns nicely with the Agile Manifesto principles, Lean thinking, and common sense.

One final request: please add comments to this post with other “Pareto scenarios” that you can think of within agile contexts. I’d love to build on the examples I provided.

Stay agile my friends,

Bob.

Quick references:

  1. http://en.wikipedia.org/wiki/Pareto_principle; the photo is from Wikipedia article on Vilfredo Pareto.
  2. http://management.about.com/cs/generalmanagement/a/Pareto081202.htm
  3. http://betterexplained.com/articles/understanding-the-pareto-principle-the-8020-rule/

Comment