Skip to main content

Fellow Scrum guide nerds, help!

Last post 12:21 pm December 31, 2015 by Charles Bradley
7 replies
12:03 pm December 30, 2015

I would like to better understand this section of the Scrum guide, from the Product Increment description:

"The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current definition of “Done.”

Key to my question is the choice of the word "deliver." The rest of the context indicates strongly that delivery to the end user/customer/production environment is not required or even the point of the Sprint; rather, delivering potentially releasable, usable and available Product Increment are the keys.

If delivery != release, then to what or where are increments of potentially releasable Increment delivered? Into the Product Increment itself, stipulating that no additional work be done? Halp1!


01:17 pm December 30, 2015

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.


03:32 pm December 30, 2015


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.


03:39 pm December 30, 2015

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)


05:27 am December 31, 2015

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.


07:57 am December 31, 2015


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


10:56 am December 31, 2015

> 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.


12:21 pm December 31, 2015

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!)


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.