3 Reasons You Should Talk About Release Schedules More Often

Release schedules drive many of the processes for IT teams. The problem is, business teams, don’t like release schedules. Maybe it’s because they don’t understand the need for the formal process or they feel release cycles slow down the delivery of new features and fixes. 

Whatever the reason, if you work as a developer or in DevOps, talking about release schedules with your business stakeholders is important.

Here are three reasons why do you need to talk to the business about releases and release schedules

Reason 1: You Want to Give the Business Teams the Right Dates

A common frustration occurs when a development team tells a business owner that the code will be complete on a set date. Then the business owner finds out they have to wait 4 more weeks before the work is available to use in production. 

This happens because the team developing the code provides a date for when they will finish their work. This is the date the team stops working on the code and starts to work on something else. But that isn’t the date the code will be available in production.

You can avoid this situation if you talk about the release schedule whenever you talk about delivery dates. 

The business team cares more about the date they can use the software not when your team finishes building it.  

Reason 2: Release Schedules Help Reduce Scope Creep and Manage Requirement Changes

If requirements change ... HA – I should write when they change! 

When requirements change, the new work may not be ready in time for the originally planned release date. The business owner needs to know the impact on the final production release date whenever they ask for new or different requirements.

If a release date is missed it can be a month or more before another scheduled release. Always talk about the impact on the release schedule when you talk about requirement changes and never assume the business teams know this.

Never assume the business knows the release date impact of a requirement change.

Reason 3: Release Schedules Help the Business Teams Plan Their Work

Most IT releases need some business inputs. It might be as simple as a business owner signing off that requested changes took effect. Or, the business users might run tests to see if everything is working. 

When starting new work with a business team make sure you talk about what that team (or person) needs to do to support the release. Because, whatever their level of involvement, the business teams need to plan their work just like you do.

Never assume the business teams know that they have input or involvement in the release process.

Conclusion

Try to include the release schedule topic in any discussions about timelines, requirement changes, and release activities. 

If you do, the business teams will have a better understanding of the release process and you might just avoid the dreaded “off-cycle release” request. More information about how to talk about off-cycle releases will be in a future article.