Like Fibonacci, there's an air of science when using like Pareto but the problem is that it's very dependent on the context. Would you like the software developers writing the code for a pacemaker to invoke Pareto? OK, so that's life critical software. How about those at Amazon saying that the code that calculates shipping costs is good enough after hitting the 80% threshold? Suppose that code overcharges on 10% of orders and you don't even realize it. You could be losing a few dollars on each shipment, multiplied by a bazillion other customers. What if you were undercharged for shipping and a friendly Fedex or UPS person showed up at the door asking for a few more dollars? That isn't the end of the world, but is certainly embarrassing for both you and Amazon. The Pareto Principle shouldn't be an excuse for doing a half-assed job!
The real issue is that we don't know if the ratio is 80/20, 70/30 or 60/40 or any other arbitrary combination. For a pacemaker I'd certainly want it to be 100/0. What if the correct ratio is 0/100, meaning that the code shouldn't have been written in the first place? By what measure are we coming to this magical 80%? Lines of code? Time spent? Budget? Finger in the wind?
When using Pareto, there's a form of confirmation bias occurring. When the principle is phrased as, "You get 80% of the value for 20% of the work", it just sounds so good that we believe it must be true. We want it to be true! This bias is the origin of most urban legends, and is the raison d'être for Snopes.com!
So, because it sounds like it must be true we endeavour to ship software quickly with that 80% of the value.
That isn't completely bad, since my experience has consistently shown that shipping smaller groups of features earlier is a more effective way of delivering most types of software. Effective feature or story splitting enables this, and it's one case where I'm more than happy to encourage obtaining feedback as early as practical. If, for example, you're still working on "must have" features as you near the end of a 12 month project, then it's likely that you haven't split those features as effectively as you could have. Again, though, why 80/20? Why not 99/1?
While I'm not the biggest fan of the research methodology behind the Standish CHAOS reports, I do think that their surveys about feature usage are interesting - that 45% of features in software are never used. Of course there's room for context and interpretation there, but it would be interesting to know in each context whether those features that aren't used were part of the 20% rather than the 80.
We also want to be careful not to use Pareto as a means to avoid work that we perceive to be difficult or monotonous. Just because something is difficult/expensive/monotonous doesn't mean we shouldn't do it. Similarly, I've often heard the phrase "low-hanging fruit" used to find features that are easy and a development team could complete quickly in order to provide a sense of progress. When I've heard this, though, it has been in a context that's devoid of any notion of what's important to the business.
I'm much more a fan of what Josh Kerievsky calls "bargains". These are features that provide value to the business that's much higher than the effort required to ship them. That evaluation of value and effort is what's really required to iteratively determine the sequencing of features.
Iterating using Pareto is good, though... perhaps get 80% and evaluate. Then get 80% of what's remaining and evaluate. Repeat until the confidence level of more than one person is high enough for the context in which you're working. Substitute the appropriate ratio for your circumstances.
So, while I have no issues with the concept behind Pareto as a means of shipping only the most important and impactful features first, I believe that the 80/20 ratio has been misused. Features have been shipped with much lower quality. The features shipped haven't been the ones that are most important to the people consuming them. Worst of all, 80/20 has been used as a way to kill conversations that could fix the first two issues.
Learn how to break features down into extremely thin slices, and deliver those with the highest possible quality. If they're truly thin, maximizing quality doesn't cost much more than shipping crap.
Comments
20% of her jobs bring 80% of the income - but without the 80% small jobs, she would never get the big ones (customers would bring some small reparation job to evaluate her skill - and only then order some big design from her).
Ever since this talk, I've seen similar things everywhere. If you don't do the drudgery of the small jobs, the big ones won't work - so by cutting the 80% that bring only 20%, you will in effect lose all.