Roadmapping Release Planning

1. Overview

There's too much work to get done in any given release, year, whatever timeframe you to define. We need ways to understand our work, contextualize it in the scheme of the library's, users', developers', and NVIDIAs' needs, and then prioritize the work to be done.

2. Scope

This document describes how roadmapping (release planning) and prioritization should be done. This is a higher level document, see the Triage Process for specifics on adding a new issue to an existing and planned release.

By the end of this document, the reader should understand how to plan a release in the GitHub Project. This process can also be followed on a smaller scale, like in sprint planning, for example.

Intended Audience: Project Leads, Developers

3. Related Processes

• Triage Process
• Project Usage
• Issue Types
• Issue and PR Hygiene

4. The Roadmapping Process

To begin, we need all issues added to our GitHub Project following our triage process. Performing the triage helps create a clean backlog of features, bugs, and documentation requests.

A perfectly planned release will have every issue within completed by code freeze - this will essentially never happen. The goal is to minimize the number of open issues at the end of the release so we do not have to continually bump issues from one release to the next. Improper planning gives the appearance to the community (and internally) that we do not have a strong handle the work we are doing.

What are we doing?

Roadmapping will never be exactly the same between releases, there are external factors such as

• Updated hardware support
• Dependency breaking changes
• Team priorities shifting
• OSS community moving directions

We will follow a small set of heuristics to build our roadmap:

1. Start from scratch each release
2. Team leads identify key items they would like to work on during the release
3. Discuss what's important with the library
4. Work top down and bring issues into the release that support the important features
5. Leave space for the unexpected

How are we doing it?

Start from Scratch Each Release

We don't want to blindly push forward on items that weren't done, maybe they weren't done because they've been deprioritized. We start from scratch to prevent scope creep, making sure we have each item within the release there for a clear and intentional reason. The less exacting we are on this, the larger each release will get over time, eventually growing into a place where the majority of issues don't get completed and roll over from release to release.

At the end of a release, for each issue that is not completed, set it's Roadmap value to Next Release. We will use this as a staging area, not wanting to lose track of issues that were important to us, but not preventing us from beginning with a clean slate.

Team Leads Identify Key Items

Prior to going to the team to build a shared understanding of importance, to facilitate this discussion the team lead(s)/product manager should understand where the library is, and its customer needs.

Take advantage of the GitHub Project and move issues/epics into the Next Release roadmap for easy identification/tracking.

Discuss What's Important

At the beginning of the planning process, the team needs to discuss the needs of the library, and the availability of the team.

We should be asking

• What are the epics that we're working on?
  • We do have epics created for all large-scale items, right?
• Are there "big picture" themes that we need to push forward on?
  • Does the release have a "soul"? ie: Release 2.2: All things CUDA 12
• Is there an internal or external need for something?
  • What's driving the release and the work we're doing?
• Is anything stopping people from using the library?
  • How do we resolve this? Are we okay with leaving those blockers in place?

Work Top Down

When we understand what's important, pulling the right issues into place is much easier. Trying to bring in issues at the same time as understanding what's important will lead to confusion and too many issues in the release.

After the team has agreed on the key items that are important to the release we can pull issues into the release:

1. For each epic we're working on
   • Determine which parts we will work on during this release
   • Add child issues (connected through task lists) to the release that support it
2. For issues not part of an epic
   • Find issues that are related to the release themes
   • Use the triaged roadmap field to help understand priority
     • Next Release > Priority Backlog > Backlog
     • Just because an issue is set to Backlog doesn't mean it won't get into a release before items set to Next Release for example
       • Roadmapping is a snapshot in time, this is a moment to re-evaluate
3. For issues that are important but not part of the key themes
   • Follow the triaged roadmap field for priority
   • Add items to the Release

How many issues should we add?

This all comes down to effort estimation and the challenges within. The Issue and PR Hygiene Process describes point estimation but at the end of the process it is still an estimation. There's no set number of points that we should add to a release however prior release point totals may be used as a good starting point.

An under-scoped release is better than an over-scoped release, both because it leaves space for the unexpected, and because we can always add more work.

Leave Space for the Unexpected

Bring in slightly less issues than you expect to be able to complete. Even with perfect effort estimation, new issues will come in mid-release that require the attention of 1 or more team members.

We also need to support rapid triage + fixes, and we do so by accounting for the time it will take in the release. A good rule of thumb is to expect 5-10% of any release to go to issues that don't exist at the time of planning

5. References/Appendix

Atlassian's guide on Release Planning for a product manager