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.