The 64:4 Principle

Most people have heard of the 80:20 principle. Very few may have heard about the 64:4 principle. The best body of knowledge on the application of this concept has been created by Richard Koch and Perry Marshall.

The 80:20 principle was originally formulated by the Italian Engineer and Sociologist, Vilfredo Pareto. It states that, for many observable events, about 80% of the effects come from 20% of the causes. While the actual figures of 80% and 20% are not important, the key observation is that a few factors cause most of the effect.

As examples, 80% of a company’s sales may come from 20% of its customers. 80% of the farmland in a country may be owned by 20% of its population. 80% of the GDP of a country may come from 20% of its industries. In the software context, 80% of errors and crashes are caused by 20% of the reported bugs. This unequal distribution is obvious and yet we don’t seem to leverage it in life and business.

Mathematically, the 80:20 principle is roughly followed by a power law distribution for a set of parameters. This implies that the 80:20 principle can be applied on itself to result in the 64:4 principle. 80% of 80% is 64% and 20% of 20% is 4% and hence the 64:4 principle. Deriving the 64:4 distribution from 80:20 the principle, we can say that roughly 64% of the effects come from only 4% of the causes. If we learn to identify and control those 4% of variables then we are well on our way to achieving exponential success in life and business.

This profound reality can be applied in the context of product development and project management. In the Agile context, this is what it means to prioritise requirements (backlog) according to value. Let us understand this through the graphic below.

Let’s assume that a project needs to develop and deliver a solution for 10 requirements. Applying the 80:20 principle to this situation will help the team plan and prioritise the requirements and effort. It is likely that 2 or 3 or those 10 requirements contribute most of the value and those are the ones the team should select for the first sprint or iteration. Of course, there may be dependant requirements that need to be worked on prior to the key ones. Those dependencies will need to be grouped to the key requirements. Further sprints ought to follow the same process to select backlog that offers the highest value.

[if gte vml 1]><v:shapetype id="_x0000_t75" coordsize="21600,21600" o:spt="75" o:preferrelative="t" path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f"> <v:stroke joinstyle="miter"></v:stroke> <v:formulas> <v:f eqn="if lineDrawn pixelLineWidth 0"></v:f> <v:f eqn="sum @0 1 0"></v:f> <v:f eqn="sum 0 0 @1"></v:f> <v:f eqn="prod @2 1 2"></v:f> <v:f eqn="prod @3 21600 pixelWidth"></v:f> <v:f eqn="prod @3 21600 pixelHeight"></v:f> <v:f eqn="sum @0 0 1"></v:f> <v:f eqn="prod @6 1 2"></v:f> <v:f eqn="prod @7 21600 pixelWidth"></v:f> <v:f eqn="sum @8 21600 0"></v:f> <v:f eqn="prod @7 21600 pixelHeight"></v:f> <v:f eqn="sum @10 21600 0"></v:f> </v:formulas> <v:path o:extrusionok="f" gradientshapeok="t" o:connecttype="rect"></v:path> <o:lock v:ext="edit" aspectratio="t"></o:lock> </v:shapetype><v:shape id="Picture_x0020_47" o:spid="_x0000_i1025" type="#_x0000_t75" style='width:451pt;height:199pt;visibility:visible;mso-wrap-style:square'> <v:imagedata src="file:////Users/venkiprathivadi/Library/Group%20Containers/UBF8T346G9.Office/msoclip1/01/clip_image001.emz" o:title=""></v:imagedata> </v:shape><![endif][if !vml][endif]

Applying the 64:4 logic to the same set of requirements will help us identify those 1 or 2 key requirements from the 10 that offers the bulk of value. It is very likely that this key requirement also happens to be the highest risk item. It makes much sense to work on this key requirement as the highest priority and strongly supports the Agile philosophy of “Win Fast and Lose Fast”.

Agile teams can benefit vastly by applying the 64:4 mindset during Product, Release and Sprint planning activities and in tackling technical debt.