Using the 80/20 rule

The 80/20 rule is so called after the Italian economist Vilfredo Pareto, who observed that 80% of the land in Italy was owned by 20% of the population. In software, the principle is particularly applied in defect fixing as it is often observed that 80% of the defects can be addressed by fixing 20% of the causes.1

Besides defect analysis and fixing I find the rule to be particularly useful when making transitions from one phase to the next in the software development cycle. For example, once 80% of the requirements analysis has been done, it is time to get into the design phase, once 80% of the design phase is completed, move into the development phase and so on. Trying to complete the remaining 20% of the work usually takes not so much effort but time. This remaining work usually ends during the middle of the next phase. There is also a tendency, especially where there are a lot of users and it is difficult to get a consensus on a feature, for issues to settle down as the issues posed by the next phase start coming up.

There is at least one situation where the reverse rule can be used. When it is time to roll out the application into production, I usually prefer to address only the top 20% of the defects found during the acceptance testing. Usually the critical and high priority defects are just around 20% of the total defects and cause 80% of the unease for the user.

Image Source

Advertisements
This entry was posted in Tips and Tricks and tagged , . Bookmark the permalink.

2 Responses to Using the 80/20 rule

  1. Hello Bhupinder, your views on managing software projects – are so well expressed. simple and brief to the point.

    your take on 80:20 is interesting w.r.t rolling out apps to production. another aspect which could also be considered is when we say ‘top’ 20% issues, what does the term ‘top’ imply? or what parameters can one consider to define ‘top’.

  2. rw says:

    Hi Venkatesh,

    Great to see you here.

    What ‘top’ is depends on the context, though most often it would be based on user/business priorities. Other factors determining priority would be the usual- maintainability, scalability, adherence to standards- at least that is what I can think off the cuff. Perhaps will post a blog on this, as of now, this blog is, unfortunately still dormant 😦

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s