Background
We have a fairly straightforward org structure:
Our Stage environment is a Full Sandbox. All sandboxes downstream of that are Developer Pro.
We added the SubDev sandboxes very recently as we now have two developers where there was one before. That is where we make code customizations such as Apex, VisualForce, etc. Any configuration changes we make as developers will also be in our personal sandboxes.
Our Dev1 sandbox is where other admins may make configuration changes. We merge our development efforts there before pushing upstream.
One last relevant tidbit: we work in two week sprints.
Question
Our Stage and Dev1 environments have not been refreshed in over six months. Our SubDev environments are not yet a week old. I envision an ideal refresh cadence as:
Stage: 4 weeks (2 sprints)
Dev1: 2 weeks (1 sprint)
SubDevs: 2 weeks (1 sprint)
But before I recommend we implement a tighter cadence, I want to better understand the advantages and disadvantages. I have done some reading on the subject, for instance here. But the article does not get very specific about recommendations. What are the main disadvantages of refreshing every sprint? Is a quarterly refresh cadence more reasonable? What disadvantages might that schedule have?
Best Answer
The main disadvantage of bi-weekly refreshes is that you may lose some time if the queue happens to be backed up. The best you can do is try to schedule Friday afternoon and hope it's ready by Monday (or whatever weekend you observe); if you lose a day, you've lost 10% of your total productivity waiting on a refresh, compared to a quarterly refresh, where a day setback would result in the loss of about 1.7% of your total productivity time. The main advantage, of, course, is that the orgs are naturally more up-to-date than a longer cycle, meaning fewer merge sessions and fewer accidental overwrites. Unless you're using a clever locking scheme, like perhaps subversion, you'll come to appreciate this.
The main disadvantage of quarterly refreshes will be noticeable if you deploy to production more frequently, which will eventually be a sticking point as it gets harder to develop and not overwrite other changes and/or keep the most recent code in the SubDev boxes. The longer you go between refreshes, the more upkeep you'll encounter unless you have some intelligent code synchronization tool to keep things organized. This means more time merging, more time tracking down accidental overwrites, and more overall housekeeping. In other words, you'll spend less time developing the longer you go. Anecdotally, just in the last week, I had to merge about 6,000 diffs into my sandbox because it's outdated, but I can't afford to refresh right now. We're not on a very strict cycle here, although we're working on it.
What seemed to work decently well at my prior job was to have two week sprints and a release cadence of four sprints, with the sprint leading up to release weekend being used only for QA, last-minute fixes to the code to be sent to production, and other last-minute activities. Sandboxes were refreshed once per release. We also had a Git repo that we'd use to sync code back from the staging org back into the individual developer orgs to keep them fresh. This minimized downtime between releases.
A proper agile implementation would want to experiment with the best cadence to use, but you should probably consider choosing a release cycle of somewhere between one and three months, and try to avoid releasing code in between those releases, except, obviously, for hotfixes/critical errors, and choose a sprint cycle that provides at least 25% of the time for housekeeping like unit test updates, refreshes, code merging, etc. The two month release cycles included an entire week of post-release refreshes and dealing with any emergency fixes/issues during the first sprint and the one week pre-release activities, like last minute hotfixes, etc, or about 75% development productivity.