Feature readiness
Last updated
Was this helpful?
Last updated
Was this helpful?
The Feature readiness step shows you the status of all work that is slated for the release. Instead of seeing only a siloed view of only project tickets or only committed code, Runway intelligently reconciles both to provide a single source of truth and a better understanding of your team's progress towards being feature complete.
In the Feature readiness view, Runway pulls together a list of all items of work for a given version, including:
Any commits/code in the diff since the preceding version's release tag
Any open PRs against the release branch
Any tickets which are explicitly labeled for the release via a “feature affiliation” (e.g. a label or 'Fix version' in Jira)
Any tickets, regardless of explicit label or otherwise, which are referred to (via commit message, PR title, or branch name) by code that is associated with the release (either 1 or 2 above)
Any code, regardless of where it lives, that refers to (via commit message, PR title, branch name) a ticket which is explicitly labeled for the release
In cases where committed code or open PRs are associated with a ticket, Runway combines those references into a single item so you're not seeing duplicated information. In cases where code has no associated ticket, or a ticket doesn't correspond to any code as of yet, Runway calls that out as well.
Items of work are divided into two tables:
Pending — Items are considered Pending when the ticket status has not yet reached the “Done” status in your project management software, or corresponding code has not yet been merged into the relevant branch. You can manually mark an item to not be considered towards overall Feature readiness percentage by clicking the “...” icon at the end of the row and selecting Ignore.
Ticket information (appears on the left side of the row)
Status — This label will reflect the current status of this item of work in your project management software.
“Done” statuses appear as green and will move the item of work to the Done table as long as the corresponding code has been merged into the branch.
All other ticket statuses appear as gray and will cause the item of work to appear in the “Pending” table regardless of code status.
Ticket name — The identifier for this item of work in your project management software, shown alongside an icon representing your project management tool (Jira, Linear, etc). You can click the icon or the ticket name to go directly to the ticket information view in your project management software.
Ticket title — Ticket title from your project management software. If truncated, hover over this area to view the full title in a tooltip.
Code information (appears on the right side of the row)
Status — This label will reflect the current status of this code relative to the release branch (or working branch, if you’ve changed the base branch on the view)
“Merged” status appears as green, and will move the item of work to the Done table as long as the corresponding ticket status is also considered “Done”
“Open PR” or “Not on release branch” statuses appear in orange, reflecting code that is expected, but has not yet arrived on the release branch
Branch and code identifier — Current branch (or destination branch for PRs) and commit hash (or PR number) for the corresponding code, shown alongside an icon representing your version control software. You can click the icon or code identifier to go directly to commit information or PR in your version control software.
Commit message or PR title — Commit message or PR title from your version control software. If truncated, hover over this area to view the full message in a tooltip.
Owner — An icon representing the version control user associated with this code (either via commit or PR). Hover over the icon to view the full name in a tooltip.
Other actions — Click the “...” icon at the end of the row to view additional actions.
Ignore — Click to exclude this item from being considered towards feature readiness/completeness. Ignored items will remain in the Done or Pending table according to normal rules, but will not be included in the overall count.
Info — Hover over the info icon at the end of the row to see a short summary explaining why the item of work was pulled into this release and how code and ticket status were determined by Runway.
Use this control to view overall progress of work items relative to the selected branch.
Hide tickets that are subtasks — Don't show tickets in this view that are subtasks of other tasks.
Only show tickets with the feature affiliation for this release — Don't show tickets in this view unless they are explicitly associated with this release via feature affiliations. If this option is OFF, Runway will pull in info for any tickets that are referenced by relevant PRs or commit messages.
If you need to get fixes into the release branch post-kickoff, you can also do this right from the feature readiness page. Fixes are work items that aren't yet in on the release branch, that your team would like to pull into the release – these can either be open PRs against the working branch, or PRs or commits that have already been merged into the working branch.
To add a fix to the release, click Add fix from the top of the Feature Readiness work items list. You'll be presented with a form to choose the work (PR or commit) you'd like to include with the fix. You can also add details explaining the need for the fix, if desired.
Alternatively, any work item that includes either an open pull request against the working branch, or a merged PR or commit on the working branch can be added as a fix for the release by clicking Pull in as fix from the action menu.
You can also add a fix to the release via Slack. The following Slack slash command will pull up a form to add a fix to the current release without ever leaving Slack:
You can take fix request approval gates even further with the optional GitHub status check: Runway will add a GitHub status check to any open cherry-pick fix PRs. The status check will prevent the merge of any cherry-pick fix PRs that have not received the necessary approval in Runway. You can enable fix request GitHub status checks by going to General > Fixes > Require fix approvals > Add pull request status check for fix request approvals.
If fix approvals are required, Runway will only automatically merge cherry-pick pull requests if the associated fix request has been approved. Fix requests can be approved from the action menu of the work item included in the fix, or from the details drawer of the fix's work item.
You can configure the following Feature readiness automations by visiting the Automations tab on this step:
Editing automation settings from an individual release will apply those changes to all of your upcoming releases for that app.
You can add checklist items to this step by visiting the Checklist tab.
If you have the '' automation enabled, Runway will auto-apply any missing feature affiliations to tickets referred to by code associated with the release.
Done — Items are considered Done when the ticket status matches one of your team's , and any corresponding code has been merged into the release branch.
Once a fix has been added, it will appear in the list of pending work items for the release branch. You can either manually cherry-pick the work item into your release branch, or if you have the into the release automation enabled, Runway will automatically take care of pulling the fix into the release via cherry-pick.
Your team can also choose to gate fixes with approvals – to enable fix approvals go to App Settings > General > Fixes > Require fix approvals. For more details, visit the .
cover any unique parts of your team's release process and live across all your releases. Steps with checklist items won't be marked as complete (green) in Runway until all checklist items have been completed (in addition to the normal criteria that would mark a step as completed).
