I appreciate new approaches to software estimation. But while this is an interesting approach, it fails to adequately address the primary issue: defining a "unit of work".
If it were possible to predict, with any degree of confidence, that task A (to do) is approximately equal to, or a 1/x fraction of, task B (completed), then the estimation problem would not be nearly so difficult to begin with.
Yet that's what this approach requires.
So cool idea, but not terribly applicable to actual projects in my opinion, unless you're able to break down projects into easily definable and predictable units of work (and yes, I know that there are various frameworks that attempt to do just that, with mixed results).
If it were possible to predict, with any degree of confidence, that task A (to do) is approximately equal to, or a 1/x fraction of, task B (completed), then the estimation problem would not be nearly so difficult to begin with.
Yet that's what this approach requires.
So cool idea, but not terribly applicable to actual projects in my opinion, unless you're able to break down projects into easily definable and predictable units of work (and yes, I know that there are various frameworks that attempt to do just that, with mixed results).