"A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." - Antoine de Saint-Exupéry One of the tricks that makes Agile work is keeping things small. In practice, small may be the "secret sauce" in Agile.
Small releases, small iterations, small teams, small queues, small user stories (the "S" in the "INVEST" acronym) -- Small is good. Small is beautiful.
One of the tricks to keeping things small is Pareto. Also known as the 80/20 rule, the Pareto Principle basically states that 80% of the effect comes from 20% of the cause.
To see how the Pareto Principle applies in Agile, consider a feature. Most of the value of a feature is in the happy path, the default scenario. The happy path is the scenario where everything works as intended with no missteps. The edge cases or exception paths carry different values, but none are likely to trump the happy path -- not by a long shot. Quality specifications inform the value of edge cases, and quality specifications may dictate that some edge cases are essential for a production release. Regardless, the happy path is where most of the value lies. Very likely the 80% value or "effect" is in the happy path.
Product Owners can break a complex user story into multiple smaller stories by separating the happy path and the exception cases into separate user stories with each story representing a unique and distinct path through the feature. The order of these stories in the product backlog would be the happy path first, followed by the next highest value exception path scenario, and so on.
Since product backlogs almost always contain more than one feature, the stories associated with one feature would almost always be interleaved with stories from other features. The Pareto Principle tells us that the value in the subsequent stories after the happy path story starts to fall off at a very rapid rate. The diminishing returns of these exception path stories means that, at some point, the value of the happy path of a "lower" value feature might exceed the value of the next "not yet started" exception path story of a "higher" value feature.
In this way, the Product Owner plays a value optimization game, sequencing the items in the product backlog by comparing exception paths of one story to happy paths of others. As stories are completed or "done," the Product Owner determines readiness for production by considering the appropriate level of quality required for the features to be deployed.
The Macro is in the Micro
The applicability of the Pareto Principle doesn't stop at a user stories and the product backlog. It applies equally well at the product portfolio level. The Pareto Principle shows us how small is beautiful. In truth, less is more.