Some changes to a Salesforce system certainly requires immediate attention, but those are rare, at least they should be if a proper change management system is established.

How I personally operate:

• Issue Management System – Early in the client interaction we agree upon a method for intaking to-dos. Ideally this would be done in Salesforce for transparency and keeping everything in context. Cases or a custom object “Requests” could be built then tied to another custom object called “Releases” which is used to manage deployments. See my “Requests and Releases” post for more details.
• Assign Story Points – Matthew/dev team will determine the relative difficulty/complexity through “Story Points” which are not meant to be equated to hours per se, but again it is a relative value. See my “Story Point Calculator” post for more on how this is determined.
• Prioritization – Each to-do should be prioritized, this also happens early in the development process.
• Scheduling – The to-dos are added to appropriate releases and executed
• Release Cycle – Typically this will be 2 weeks starting on a Wednesdays
  • Wed, Nov 22 – Previous release is deployed
  • Thurs, Nov 23 – DEV and TEST sandboxes is refreshed, (work begins once refresh complete)
  • Fri, Nov 24-Friday, Dec 1 – Release work, dev cutoff end of day Fri, Dec 1
  • Mon, Dec 4 – Push changes to TEST environment
  • Tues, Dec 5
    • Send Release Notes to “All Salesforce Users” Salesforce Group
    • Deploy change set from DEV that was passed and verified to TEST into PROD
      • Validate but wait to deploy until the next day
  • Wed, Dec 6 – Release day! Deploy from DEV the change set validated on Tuesday
  • Repeat cycle