In scrum, when do developers typically check their sprint code into production?

Question

Is it prior to the Sprint Review?

Does the definition of done include "Code checked into production"?

If not, when do they check the changes in?

Right now, this is our process:

• Developers code changes on their local machines
• They write/run Unit Tests
• They do sanity integration tests on their local machines
• They go thru a design review
• They go thru a code review
• They check in the code to production
• The code gets tested by QA
• The code gets released -- meaning customer can upgrade if they want.

Our product is a B2B product that other businesses use. Customers go through internal processes to upgrade (that includes testing) and they don't always take every release we make available.

Answer 1

This is going to be highly dependent on the context.

I'll start off by saying that "checked into production" doesn't mean anything. Is that "checked into an integration branch in source control" or "checked into the main branch of source control" or "deployed to production"? All of those can be very different things, all of which could be viable for a team's Definition of Done.

There are a few baseline rules to start with. First, the Definition of Done needs to be achievable. Each unit of work should meet the Definition of Done within the Sprint. The overall Increment needs to meet the Definition of Done by the end of the Sprint. Second, any work necessary to achieve the Sprint Goal needs to meet the Definition of Done by the end of the Sprint, which is at the Sprint Review and Sprint Retrospective. Third, the team should work to make the Definition of Done more stringent over time.

In a case where I was working with teams on a complex hardware/software system, the Definition of Done was that the work was integrated into an integration-ready build and available for the system integration team. This implied designed, developed, tested with unit and integration tests, peer reviewed, tested against a simulator or emulator, and ready to be installed on physical hardware in an integration setting for additional testing.

In another case where I was working with teams on a web application, the Definition of Done was that the work was merged into the development branch in source control. The design and development was complete, testing was complete, and the independent verification team understands the changes and the required testing at a system level.

In both of these cases, any work necessary to achieve the Sprint Goal had to meet the Definition of Done prior to the Sprint Review. It doesn't say when the Sprint Goal had to be achieved, though. Sometimes, the Sprint Goal was achieved days before the Sprint Review, and an Increment was ready to go.

The use of Continuous Integration / Continuous Delivery / Continuous Deployment is also a factor here. In order to take advantage of CI/CD, you need to be integrating frequently, perhaps even merging work-in-progress to upstream branches and using feature flags and keystone interfaces to control the environments where the work is visible and how stakeholders can interact with it to provide feedback.

Answer 2

Refer to the Definition of Done (DoD) and Working Agreements

In [S]crum, when do developers typically check their [S]print code into production?

There is no prescriptive answer within the Scrum framework, and it's not defined by the 2020 Scrum Guide. Additionally, "delivery" in a Scrum sense is not strictly aligned with the Sprint Review, which is meant for reviewing the work delivered during the Sprint, and soliciting stakeholder feedback beyond any collaboration the Scrum Team has with them throughout the Sprint.

Instead, when code moves from development to production is really a process concern that should be informed by one or more of the following considerations:

1. The organizational objectives, e.g. continuous integration (CI), continuous delivery (CD), or continuous deployment (the other meaning of "CD").
2. The Definition of Done agreed upon by the Scrum Team, usually in collaboration with the Product Owner's input on behalf of stakeholders.
3. Any working agreements with the organization or other teams outside the Scrum Team.
4. The technical capabilities of the team, such as the availability of CI software and knowledge of continuous delivery/deployment techniques.
5. Whether the Increment represented by the Sprint Goal is "potentially deliverable" or actually-deliverable.

As a Scrum Team is self-managing but answerable to project sponsors and organizational leadership, what to build is generally defined from outside the team and managed by the Product Owner, but how to build is up to the Scrum Team. On the other hand, how and when to deliver is very much a grey area, and the Scrum Guide is largely silent on this issue except to say that each Increment must fit within a single Sprint and meet the Definition of Done even if it's not actually deployed or shipped within the Sprint.

Answer 3

Adding to the answers you already have...

An increasingly common approach is to release code when it is ready, regardless of when that happens in the sprint. The use of feature toggles allows this to happen and means we can separate out 'release to production' from 'release to customers'.

So, the general rule is:

• Release to production behind a toggle when it is technically ready to go
• Release it to the customers (flip the toggle) when the Product Owner and stakeholders agree it is ready

This approach also makes it easier to do step releases, canary releases, etc. which can help to reduce risk. For example, the code may be in production behind a toggle. The next step is to toggle it on for 10% of your customers. If that works well then you increase the number of customers that see the new feature.

Answer 4

Pushing code to production is the latest step in the journey of a code. Here are the steps I use;

1. Developer creates a feature branch on source control related to a story/task
2. Developer pushes code ( including test code ) to the feature branch
3. The "continuous integration" service runs the tests on the feature branch
4. The code is reviewed by peers with a pull request
5. The code is merged to the develop branch
6. The feature is tested by the quality assurance team
7. The feature that passes the quality assurance team tests goes to the UAT of the product owner
8. The feature that passes the UAT of the product owner is presented in the sprint review
9. The feature that passes the sprint review can be added to the next release
10. The operations related to releasing the next version are new stories for another sprint, and merging the release to the master branch, deployment, and sanity checks are part of it