4. Use the 80/20 rule.

That last comment made me think of this thought. Imagine that the client asks for 100 features to be delivered in one year. In a waterfall project this is a common thing said one year later: "well, we don't have anything. But if you give us three more months we will have EVERYTHING." Yeah right.

Are you skeptical that this happens? Remember the chaos report, and probably some of your own project experiences. How many projects finish on time? In iterative development, at the end of the year we always have something, but often it is a subset of the whole. That is still a huge improvement over waterfall where you might have nothing.

Ok, so at the end of the year we have 20 of the 100 features implemented. When we tell that to the customer, how will they feel? Probably pretty unhappy. But only if we focus on counting features instead of focusing on value. According to the 80/20 rule, 80% of the value of a thing comes from 20% of the content of a thing.

If you listed the 100 things you liked least about your significant other, then fixed 20 of them, your relationship would be 80% better. Another example: 80% of the work gets done by 20% of the team.

You get the idea. So, if we picked the RIGHT 20% of the requirements, we might still deliver 80% of the value! If the system was going to grant $100K in new revenue, perhaps now it will only deliver $80K. If there was a business case for 100, there is probably one for 80. And remember the chaos report. Typically customers get 0%!