I’d like to define what “usable” means. Let’s look at the Scrum Guide 2020:
“Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.”
“In order to provide value, the Increment must be usable.”
Creating standard CI/CD or working on a database is almost certainly not enough. But in my opinion, sometimes it can make sense to work on internal value, which is useful internally. This is when you can use an Increment to lower the risk and deal with complexity by validating a hypothesis. For example, if the greatest complexity is in technology, I can imagine that a technical Spike may be a valid Sprint Goal. After all, what will be the value of the product if the technical assumptions turn out to be wrong?
We are dealing with complexity, which has many different dimensions. Customer’s needs and expectations are only one of them. Each Sprint should give you an opportunity to learn something new, to close a feedback loop. This is what empiricism is, isn’t it?
so why isn’t it OK as it is with leaving it vague and open for interpretation and context?
That’s a good question @Tamás Hajdu These 2 quotes are quite important, I don’t like it being so vaque. An alternative could be to remove it completely or to add some alternative condition (other than usable).
My intention is to open the discussion, see if others think alike, and if so, look for possible solutions.
Remember scrum tells you what to do and not how to do it. Thus “useable” is the what, but the details is up to the organisation to define what uable means for them. Different companies will have different meanings to what that means, which is okay. As long as that usable meets the definition of done, I am okay with the guide as is.
Anything that is open to interpretation without even an example to guide is basically just spacing to be ignored. Either define the word or use another that fit the actual meaning.