Releases

What is a Release?

A release is a new version of the product that represents a set of completed goals and delivers new value to stakeholders.

Release Planning

Release planning is a precursor to sprint planning. Releases identify the high-level, long-term goals that will guide which issues are assigned in upcoming sprints. Release planning and sprint planning can be simply distinguished by the following questions:

• During release planning, the team asks, "What should our goals be?".
• During sprint planning, the team asks, "How do we best achieve our goals?".

Who is Involved?

Release planning involves the Product Owner and other internal stakeholders such as the Heads of Support, Marketing, and Development who are responsible for deciding the business needs and priorities of an upcoming release.

Focus on Stakeholders

Release planning is focused on the needs of stakeholders. While a stakeholder is technically anyone with an interest in the project, it is most important that the team delivers continuous value to the end users of the product, which include the following roles:

• Existing User - uses the product to server their own needs or the needs of an organization
• Potential User - considers using the product but has not yet taken action
• Developer - develops the product or solutions that implement or extend the product

Components of a Successful Release

A successful release should address at least one new benefit, pain point, and barrier. In doing so, the team ensures they are consistently delivering value to both existing and potential users, as well as the developers who implement and extend the product. This allows the business to maintain a satisfied user base while growing its appeal to new users over time.

1. Benefit

• Audience: Existing User, Potential User, Developer
• Definition: A new benefit is value realized from functionality that did not previously exist. It increases the appeal of the product to existing and potential Users, and possibly developers.

Note: Release planning intentionally focuses on "benefits" instead of "features" in order to generate discussion around added value as opposed to technical implementation.

2. Pain Point

• Audience: Existing User, Developer
• Definition: A pain point is a problem with existing functionality that may turn existing users away because of a frustrating or broken experience. Addressing pain points shows the user base that the team is invested in their success and creates long-term customer relationships.

3. Barrier

• Audience: Potential User
• Definition: A barrier is a lack of functionality that prevents potential users from adopting the product or turns them towards an alternative. If the team commits to removing at least one barrier with each release, then the pool of potential users is more likely to grow over time.

Identifying Priorities

When deciding which feature, pain point, or barrier to address, team members should discuss the user stories associated with each proposed change. In doing so, the team will gain a sense of which goals create the most value based on the rationale of the change and the potential audience it could impact.

Release Schedule

Releases should be planned one minor point release ahead. So when version 2.0.0 releases, the planning of 2.1.0 should begin. This provides enough focus to guide upcoming sprints while remaining agile and able to adapt. Longer-term planning can still occur within epics but should not be associated with a release that is farther out than one minor point release.

Release Reports

Release reports provide visibility into multi-team, multi-sprint goals to alleviate the unknowns that come with planning long-term deliverables.