Definition of usable?

It has to be usable enough for lessons to be learned about it which are based on empirical evidence.

If customers are internal, will the evidence so gathered be sufficient to allow the inspection and adaptation of a demonstrably valuable product?

Thanks Ian - I'd say that at least some lessons could be learned about it, given that internal users (eg editors) will need to use elements of the product.

On thinking further, perhaps my issue is that most of the projects I've worked on wouldn't provide anything that an external customer could use by the end of the first sprint. So I'm trying to understand whether it makes sense to break down the definition of "usable" to the point where you can say that yes, component A is done and usable even if components B through Z aren't near that point yet.

So I'm trying to understand whether it makes sense to break down the definition of "usable" to the point where you can say that yes, component A is done and usable even if components B through Z aren't near that point yet.

Usable should mean fit for release. The release environment is always something to be determined. It might be an entire customer base, or it may be a subset which has been selected in order to conduct specific, empirical tests. A small change might be appropriate for a controlled split test to be carried out, for example.

One of the defining characteristics of an increment "fit for release" is that it ought to represent some sort of feature, or a collection of features. Features themselves ought to be usable and of demonstrable, empirical value. User stories are a common means of representing them. Value does not necessarily mean money, it could be a useful lesson which confirms or refutes an hypothesis about product scope. "Components", unless they actually are features, may not represent something useful like that.

Yes, "feature" is probably a more appropriate term here than "component". Thanks, that helps.