I don’t think value corresponds cleanly with size. Some high-value requirements will be small, and some low-value requirements will be large.

Sizing of work orders wouldn’t really be comparable between teams. Value delivered, however, is comparable. Value should probably be determined by a customer model in the front end of analysis. QFD’ish methods like Kano Analysis and Analytic Hierarchy Process will help here, and it’s why I choose to start with a customer representation like use cases rather than jumping directly into functional requirements. User scenarios are easier to value than product functions, but that value is somewhat independent of the size of the expression.

Feature Driven Development provides a very good example of controlling the size of work orders by applying a standardized requirements specification schema. I’m not exactly saying “do FDD,” but I’d use that as a benchmark. Imagine an XP-user-story-like scope + FDD-like syntax + QFD-like operational definitions. Somewhere between FDD and the First House of Quality lies the Golden Path.

“A goal for our descriptions of atomic use cases is that they should all
be of a similar size”

I’m finding this to be one of the trickier aspects of accounting for value. What does size really mean? How likely is it that two teams will size something in the same way and what happens when management wants to compare the aggregate output of one team to another? Although, I’d like to focus more on the flow first but it seems like a bridge too far for some.

Does size refer to estimated effort to complete? The amount of value the client has given to the story? Or are we looking at some multifactorial scheme?

It seems like when we are dealing with 1000′s of stories, it gets a little easier to smooth out the differences. But that’s a very macro view that most of us in the trenches don’t get the “luxury” of worrying about.