Release planning process

There are three distinctive characteristics that influence our release planning process:

1. Agile development cycle

2. Time-based releases

3. Release planning cadence

Agile development cycle

The waterfall model follows a linear approach to software development where each phase in the process only begins after the previous phase is complete. The intent of this approach is to deliver a feature to customers once all the agreed upon requirements are completed.

An agile methodology is a more iterative approach. Components of the work is shared with customers as they are completed for feedback and validation - this may include Beta releases, prototypes or even wireframes during the design stage. The intent is that customers have more opportunities to influence decisions and enables development teams to change direction faster if needed.

Mattermost uses the agile methodology for development because it supports iteration and allows the product team to get closer to our customers and users. This is also the model that development teams have been adopting in recent years.

This means our release planning process is also agile. We continuously iterate our priorities based on new feedback and painpoints we receive, and treat our release plan as a continuously evolving, living document. Therefore, typically we lock the release plan for a quarter. The next quarter’s work is usually queued, but there is some flexibility to changes prior to beginning development. Work planned for more than two quarters in the future is very flexible to changes and reprioritization.

Time-based releases

In a feature-based release cycle, you release when a given set of features is implemented. Thus, there is no release date set until the work is complete.

In a time-based release cycle, you release at a predetermined date with whatever features are ready at the time. As a result, some features may be pushed to a following release, but the release date itself does not change.

Mattermost uses time-based releases for the following reasons:

• Trust: Having a predetermined release date increases predictability as it enables organizations to plan their own upgrade cycle.

• Iteration: Having a set release cadence enables us to release new features and bug fixes early and often; in a feature-based release cycle, a release may get delayed by days or even weeks if surprises arise during the release cycle.

• Community: A time-based release cycle is preferred among developer communities, especially in open source. Contributors are aware of the release schedule and often aim to complete development by a specified date so that the feature makes it into a release. However, if those dates are missed, we can simply deliver the community-built feature on the next release. Doing feature-based releases with the community is risky, since there is generally less influence on when exactly the work is completed.

You can find step-by-step details of the release planning process and timelines at https://handbook.mattermost.com/operations/research-and-development/product/release-process.

Release planning cadence

At Mattermost, our planning cadence consists of:

• Yearly: Company fiscal year and long term product strategy planning

• Quarterly: Release Plan and Quarterly OKR planning

• Monthly: Check in on OKR status

Since we follow an agile development style, our release plan is also agile. We plan releases quarterly, following the process outlined below.

Before each quarter begins, we lock on plans for:

• What's Launching: Key initiatives we plan to work with Marketing on launching this quarter.

• What's In Progress: Key initiatives we will start working on this quarter, but may not ship until a future quarter.

We also update the backlog to show which items we are considering for 6 to 12 months out, but this list is flexible and gets updated each quarter based on any changes to company strategy, product goals, community needs, and market conditions.