Thinking back to how we value our work, we must recognize that, in software, quantity is not value!
The number of things we do in a sprint does not vary too much, we can consider it a Gaussian (assuming correct and consistent measurement) — or in Black Swan (TBS) parlance: velocity is a variable from Mediocristan. However, the value of each item does not follow a Gaussian — in Black Swan parlance value per item is a variable from Extremistan. It is conceivable to think that we can have one item that accounts for 90% of the value we deliver, in fact that is most often the case, but even knowing this we may underestimate (or lack understanding of) the real extreme value of an item.
What does that mean in practice? How does this affect our planning or item selection? Can we in anyway predict the value? (not, according to TBS)…. The payoff of a “large value” item would however be much bigger! (altavista vs Google)
In my view, given the current knowledge I have of the software development process/world, I’d say that this assertion means that the most value in a software development process can be obtained by concentrating on selecting those extreme value items that can make the software a success. Current science and practice on this, however, seems to lack any repeatability or reliability when it comes to reliably selecting the “killer” features… Do you have any links to papers/articles about value focus in the requirements selection process? link them up in the comments section.