Fellow Scrum guide nerds, help!

Delivery of an increment means that it should be considered fit for potential release.

The best environment to release into is a production one, because that allows an early return on investment, minimizes depreciation of work-on-hand, and allows data to be obtained under market conditions.

Delivery into a pre-production environment is sub-optimal, as undone work will accumulate and there will be a deficit for release. If this occurs, the team should try to improve its Definition of Done so work is delivered closer to production.

Jason, good question, Ian's answer was pretty good, and I'll take a crack at it too.

I don't think Scrum cares where the artifact gets physically delivered to. What Scrum cares about is that the incremental is Done/Releasable/Usable, no more development needed, etc as you say.

One thing worth mentioning also is that Scrum is not a framework for software deployment, software release, or software operations. It is a software *development* framework. Once the increment is truly releasable, where-ever it may reside physically, the "jurisdiction" of the Scrum framework ends.

Ian,

> Delivery into a pre-production environment is sub-optimal, as undone work will accumulate

Ian, while "undone work"(in the layperson interpretation of that phrase) may accumulate, is it necessarily true that undone "software development" work accrues? (I could see how undone software deployment work would be present and/or accrue)

I can't speak for the rest of the world, but the term "pre-production" environment in the USA generally means "our non prod environment that most closely resembles prod, and is the last place we do testing." Assuming one had delivered it to pre-prod, and that pre-prod was an adequate environment for doing final testing, and we did said final testing adequately, I could see how pre-prod might be an acceptable place to deliver an increment to know that it is potentially releasable. Then, from a "Scrum jurisdiction" perspective, it is a potentially releasable increment that has been delivered, and no further software development work or testing need occur.

Having said, that, I'm in 100% agreement that delivering to prod is the absolutely best way to assess value delivery, prove that it was "done", etc. But that's not required by Scrum, nor the delivery to prod really the "jurisdiction" of Scrum. (As an excellent complementary practice, I could see a Scrum Team doing the delivery to prod, but again, not required by the Scrum Framework)

The objective is to release work into production so it can be put to best and fullest use. The more work is batched prior to release, the less optimal is the agile delivery of it.

Scrum makes no concession for pre-prod environments...not even for those which are technically equivalent to production in every sense. Nor does it draw a distinction between undone development work and the work needed to facilitate deployment into production.

If a team delivers work into a pre-prod environment of high fidelity, this implies that little undone work of any sort remains. However it will still not be entirely eliminated.

Note that even if release *does* occur into production...but the increment's functionality is restricted by means of (say) feature flippers...then there is still a deficit for release. Logically it's still pre-prod, because the functionality will not be available until somebody flips the switch. What matters is whether or not the Product Owner can release that functionality immediately and at will. Anything that gets in the way constitutes undone work by the Development Team, and it should be addressed and taken care of in their Definition of Done.

My interpretation of Scrum's "jurisdiction" is that it encompasses all activities up to and including that release into production. It isn't just about making an increment "potentially releasable" or "potentially shippable". Release into production allows the Scrum feedback loop to be properly closed.

Ideally the development and deployment should be independent. Scrum team will keep developing the product and will give it to PO, let PO decide when and which feature he would like to release to his customers.

Regards
Sanjay

> Ideally the development and deployment should be independent.

Ideally deployment into production should take no effort. Development will have prepared the increment for immediate release by the Product Owner, at his or her discretion. The work involved in making that release should then be negligible.

The complexities of making a deployment, so that immediate release can be effected, are best seen as part of the development effort. They exist on the same continuum. This is clearly the rationale behind DevOps, but it is germane to Scrum also.

Ian,

> My interpretation of Scrum's "jurisdiction" is that it encompasses all activities up to and including that release into production. It isn't just about making an increment "potentially releasable"

We are in respectful disagreement on this point, and all logic that flows from this point will also put us in disagreement, which is fine. I'm not sure I'm 100% right on this one anyway. Just my best Scrum Guide nerd effort here.

Where we are in agreement is that value can only be captured via a release, and "Done" can only be 100% proven via a release. I think one could also argue that if you're not releasing to production at least every two months, then you might be doing Scrum but might not be Agile. (I actually learned that line of logic from you I think, Ian, on a post on here -- I like it!)