A recent discussion on the Extreme Programming mailing list addressed whether there is an "80-20" rule in software development. Let's take a look at some numbers.

For the sake of simplicity, we’ll assume projects where all the requirements stories are of equal cost. Extension of the reasoning to more complex situations is left to the reader.

We all know that the proposed features for a software product vary widely in value. We’ll consider three ranges: a project where the most valuable feature is worth three times the least, one where the ratio is ten to one, and one where the ratio is twenty to one. In my experience, even this last ratio is not out of the question. One of the posters to the mailing list indicated that the stories on their project were valued at 50, 10, and 1.

Of course we have probably all dealt with feature suggestions that have negative value to the project, but we won’t go there. For realism, you might want to add those in to your own model.

## Equal Distribution

Suppose that we have as many high point stories as we have mediums and lows. Then we can assess the project very quickly, using our assumption that all the stories are of equal difficulty. We can consider, without loss of generality, that there are only three stories: a low, a medium, and a high.

### One, Two, Three

So let’s begin by supposing that we’re on a project where the best feature ideas are worth only three times the worst. We’ll look at some increasingly complex situations.

There’s an obvious way to do this project – and all the projects in this article – do the valuable stories first. So let’s look at the situation for this one. <table border="1" width="50%">

Iteration Value Value Percent Cost Percent 1 3 50 33 2 2 83 66 3 1 100 100

</table> Well, even with a ratio of just three, this is pretty interesting. We can get half the value at one-third the total cost. It takes us two-thirds of the cost to get over 80 percent, though. So it’s not exactly a real 80/20 rule. But let’s look now at the table for a ten to one ratio in value. We’ll suppose that the values are 10, 5, and 1 this time. <table border="1" width="50%">

Iteration Value Value Percent Cost Percent 1 10 62 33 2 5 93 66 3 1 100 100

</table> Now we’re getting somewhere. One-third the cost gives us 62 percent of the value. Still not 80/20, but pretty darn good. What about that twenty-to one situation? <table border="1" width="50%">

Iteration Value Value Percent Cost Percent 1 20 65 33 2 10 96 66 3 1 100 100

</table> Can you see what’s happening? If we assume that the stories are valued 1, N, and N/2, the results are approaching 2/3 of the value in the first iteration, and 100 percent of the value in the second, with essentially nothing added by the third iteration. So we are approaching not an 80/20 rule but certainly a 66/33 rule: two thirds of the value at one-third the cost.

## How to Get Eighty-Twenty

What would have to be true for a project to have an 80-20 distribution? Well,to get a twenty, it has to have 5 (or 5*N) iterations. We’ll assume 5. And there would have to be one story that was worth, say, 16, and four that were worth only one each. That’s not as radical a distribution as it might sound: we were considering a ratio of twenty to one up there a minute ago. It turns out it’s the middle-sized stories that got in our way. So if you had one good idea, and four times as many frills, it would look like this: <table border="1" width="50%">

Iteration Value Value Percent Cost Percent 1 16 80 20 2 1 85 40 3 1 90 60 2 1 95 80 3 1 100 100

</table> Is that so hard to believe? Not for me. Four times as many bad ideas as good one, and bad ideas sixteen times worse than good ones? I’ve seen lots of customer-types do that!