What’s 80-20 rule?

Also known as the Pareto Principle, the law of the vital few, and the principle of factor sparsity, states that, for many events, roughly 80% of the effects (output) come from 20% of the causes (input). In the early 1900’s it was observed by an Italian economist Vilfredo Pareto, that there was an unequal distribution of wealth in his country where 80% of the land was owned by only 20% of the population. While originally pertaining to economics, this phenomena was observed by other professionals in their own areas of expertise.  In business for example, 80% of your sales come from 20% of your clients. In the software domain, many experts note that if you develop 20% of the highest priority features, you’ll satisfy 80% of the business needs. Moving on…

What’s The Standish Group’s statistics on software usage?

Jim Johnson, Chairman of Standish Group, reported at the Third International Conference on Extreme Programming (XP2002) that in typical software systems 64% of features are never or rarely used in reality. This was largely apparent in systems where up-front plan and design were done before business ROI was considered or even knowable. What’s more interesting is that from a positive point of view, 20% of these features are used always or often used!

Merging the two to get the highest return on investment for the business!

So, it should follow that if we can prioritize our requirements (stories) and work on the most important 20% of our backlog (list of epic stories), then we could ultimately satisfy 80% of the business needs. At the same time; once this initial 20% of the features are in production, it will also be used by the business predominantly (always or often). The most important part of doing this effectively is finding that initial 20% of the requirements that return 80% of the clients satisfaction. An valuable Product Owner will be able to prioritize and understand that not every feature is high priority. I believe that the more you understand your business, the easier it is to arrange your priorities. That’s why an effective PO is the foundation of delivering valuable business features.

In Practice:

I’ve witnessed the 80-20 rule apply itself over and over again in our industry and also in my position. Software products developed where an equal amount of effort was put into building low priority features as it was to build the high priority features. At the end of the day, the return on investment was inherently lower on those features which customers rarely or never used or were unimportant. Effort is lost or wasted, which could have been allocated to more important features or features that that will be used more often. If you’re working on a project with unlimited budget then this could be OK, but I’ve yet to see one in real life (nor do I ever expect to).

This is not to say that any feature that is not used often or always is unimportant. Sometimes a feature that is used rarely is important to the business; in that case the priority would be high and likely moved up the priority list. But more often than not, if a feature is used often or always, it is likely to be a higher priority feature versus features that are used rarely or never (obviously). The better the Product Owner, the more fine grain each priority will be.

My humble advice:

If given adequate time on a project, module, or epic story, by working on the highest priorities first, as soon as you reach the most important 20% anything after that is bonus. Continue working on the time-boxed iteration or release plan, delivering beyond the initial prioritized 20% if you can (reach 55%), but remember that your effort-to-results ratio will diminish dramatically the further you go to fulfill 100% of the features. You could move on after the initial 20% to another important module, or work until the time-boxed iteration (fixed amount of money) runs out. A good idea after building the initial priorities is to stop and get feedback. Feedback is a time for the business to learn and for the development team to adjust if necessary. I can almost guarantee that the business will ask for something else that they originally didn’t plan to or have other opportunities come up that change priorities for what is important now.

Focus on the 20% that matters:

It’s not to say that the other parts of the software are not important, but that you’ll get more return for your efforts if you focus on the most important 20%. Here’s an example of how this works:

By working on the highest priority features first, and releasing early the customer has an opportunity to learn from the market (2 pre-releases occur before the project release date). Also the business has a chance to realign it’s next priority needs if necessary. The highest prioritized features are delivered earlier in the project, usually before the project is over or the money runs out. These features are the ones that will be used always or often by the business. An added bonus is that the company can actually start making money (earlier than expected “$” shown on the diagram) during these initial releases. As a consequence the software is bringing income into the project allowing it to partially fund itself. I’ve witnessed many projects partially funding itself first hand so this is not a hypothetical situation. If time/money does run out before the entire product backlog is complete then you’re still in a good position because you’ve already met at least 80% (if not more) of the business needs. In the example diagram above, we’ve delivered over 55% of the features. What’s remaining in terms of features are never used (according to the Standish Groups report on software usage). I wouldn’t go so far as to totally ignore the remaining features, but I would agree that they are far less appealing and less rewarding to work on than the initial 55%.

Prioritize and focus on what matters the most, you’ll see more benefits emerge with less effort. Ask yourself the question “What are the priorities and are we working on the ones that we value the most“. You’ll see it applies to many other aspects of life, not only the software business!