Should the increment produced every sprint really be “useful? Isn't usable enough?

I'm not sure when the "Gone Are Release Planning..." post was written, but I'd guess that it was written sometime in the fall or winter of 2011, shortly after the July 2011 Scrum Guide was published. Understanding that context is essential, because over the ~14 years since it was written, the notion that "the practice of software releases exists because it is not always practical to constantly deliver what is being built" has changed.

One of the most significant changes was a deeper understanding of and support for feature toggles/flags, as described in this October 2017 article by Pete Hodgson on Martin Fowler's blog. You also had companies offering tools and services for feature flags launching, like LaunchDarkly in 2014. This isn't to say feature flags were new, because they weren't. A confluence of other events led to their rise in popularity. This really made continuous deployment possible for more organizations, where it was too risky before. Although not applicable to all environments, the need for batching changes into a larger release decreased for many teams.

The ability of teams to deliver software more frequently led to a shift in thinking. The ability to deploy partially done features behind a feature flag enabled teams to integrate into their baseline more frequently. This also enabled the delivery of bug fixes and minor enhancements while maintaining a stable baseline. The overhead of branching and controlling when changes were integrated became much lower. I would suggest that the ability to deliver bug fixes and minor enhancements which would solve problems, would result in not only a delivery of changes behind a flag but also useful, user-facing changes more regularly.

Even if you're not able to deliver a larger feature because it won't be fully usable until a couple of Sprints, you can enable what does exist in demonstration and test contexts to get feedback as well as deliver other useful changes with much less management overhead.

In the end, I think this is a shift to the team not only accomplishing their Sprint Goal in terms of what they can review (perhaps in a development or test environment), but in trying to deliver something useful each Sprint.

Should the increment produced every sprint really be “useful? Isn't usable enough?

The Scrum Guide says that the Developers commit to making sure the Increment is usable, while the entire Scrum Team is accountable for making sure it is useful.

Usable is a matter of quality. Useful requires that increment also has value.

My short understanding:
If an Increment is not usable, there is a problem — it has not met the Definition of Done. And if it is not useful, we should ask why it was built in the first place. Every Increment should provide some form of value, even if the value is cumalitive and not immediately released. I find the rephrasing from “potentially releasable” in earlier Scrum Guides to “valuable, usable Increment” a more practical perspective.

My personal view:
I see this through the evolution of Scrum alongside modern CI/CD pipelines. Teams now continuously integrate and test new code, with automation ensuring each Increment is production-ready. While the Scrum Guide does not mention CI/CD directly — and I realise this view is sector-specific — in practice, that is where a Done Increment should end up in software development: working, tested, and ready to deliver value whenever the Product Owner chooses to release it.

Thanks for your invaluable insights. It was a pleasure discovering your perspectives.

I'm still puzzled on the potential overlap and/or difference between the words valuable and useful, since they are sitting next to each other in the same sentence in the Scrum guide.

Just as a quick note, I'm seeking clarity because I'm preparing for the PSPO I examination.

Thanks.