Pareto and You—Separating the Wheat from the Chaff

Pareto and You—Separating the Wheat from the Chaff

You are currently viewing Pareto and You—Separating the Wheat from the Chaff

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.

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

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

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%.


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.

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
  • 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
  • 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
  • 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.


  • 20% of the Release Plan will contain 80% of the
  • 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
  • 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.

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,


Quick references:

    the photo is from Wikipedia article on Vilfredo Pareto.

Leave a Reply