Concorbit HelpAll guides →

Backlog & RICE

Backlog and RICE Scoring

The Backlog view is the prioritised list of every feature across every product, sorted by RICE score so the highest-value work is at the top. It is the page PMs live in during prioritisation sessions, and it is where you trigger the dev handoff to the Projects module.

URL: /pm/backlog
Required permission: pm.view (status changes and dev handoff also require pm.edit)

What the Backlog Shows

The backlog is a single sortable table of every feature in the tenant, with these columns:

ColumnWhat it shows
#Rank (1 = highest RICE)
FeatureFeature name, clicks to the detail page
ProductProduct the feature belongs to
Prioritylow / medium / high / critical badge
StatusInline dropdown, change status without leaving the page
ReachRICE reach score (1-10), read-only here
ImpactRICE impact score (1-10), read-only here
Conf.RICE confidence score (1-10), read-only here
EffortT-shirt size badge: XS, S, M, L, XL
RICEComputed score, see formula below

Rows are always sorted by RICE descending, paginated 50 per page. A RICE of 10 or higher is rendered in accent colour to signal high-value work; 5-10 is dim white; under 5 is very dim.

RICE Scoring Explained

concorbit uses the standard RICE prioritisation formula:

RICE = (Reach x Impact x Confidence) / Effort

Each component:

  • Reach (1-10): how many people will this affect in a given period? 1 = a handful of users, 10 = everyone on the platform.

  • Impact (1-10): how much does it move the needle per person? 1 = minor convenience, 10 = critical job-to-be-done.

  • Confidence (1-10): how sure are you of the Reach and Impact estimates? 1 = hand-waving, 10 = validated with data.

  • Effort: T-shirt size, converted to numeric: xs=1, s=2, m=3, l=5, xl=8.

Worked example

A feature scored Reach 8, Impact 7, Confidence 6, Effort M (= 3):

RICE = (8 x 7 x 6) / 3 = 336 / 3 = 112

A competing feature scored Reach 9, Impact 9, Confidence 5, Effort XL (= 8):

RICE = (9 x 9 x 5) / 8 = 405 / 8 ~= 51

The first wins despite lower raw reach because the effort is so much smaller. That is the point of RICE: score large by value, divide by cost.

Where RICE is calculated

RICE is computed on the fly every time the backlog or a feature detail is loaded. It is not stored. Re-scoring a feature instantly changes its rank. The formula lives in PmFeature::riceScore() in the codebase if you ever need to audit it.

Editing Scores

The individual R, I, C, and Effort values are not editable inline on the backlog. To change them, click the feature name to open its detail page and click Edit, or go direct to /pm/features/{id}/edit.

The edit form lays out all four components together with a live "RICE Score: NN" preview that recalculates as you type. The values are capped at 1-10 for Reach, Impact, and Confidence; Effort is a fixed XS-XL dropdown.

Changing Status Inline

The Status dropdown on each row updates immediately via a PUT /pm/features/{id}. Available statuses:

StatusMeaning
backlogCaptured, not yet triaged
under_reviewBeing evaluated or scored
plannedApproved for a release
in_developmentEngineering is building it
testingIn QA / UAT
shippedDelivered
wont_doExplicitly declined

Status changes require pm.edit. Marking a feature as shipped or wont_do additionally requires pm.manage. Transitions are also sequence-enforced: you cannot skip steps (for example, jumping straight from backlog to shipped), and an illegal jump is rejected rather than applied.

Filters

The backlog has a single product filter dropdown in the top right. Select a product to narrow the list; select "All products" to clear. The filter is the only one on this page: there is no status, initiative, release, or priority filter here. If you need richer filters, the full features list at /pm/features accepts status, product_id, priority, and initiative_id query parameters.

Dev Handoff: Create Project

Once a feature has been scored and planned, you hand it to engineering by opening the feature detail page and clicking Create Project.

What the button does: POST /pm/features/{feature}/create-project creates a new project in the Projects module with these inherited values:

Project fieldSource
NameFeature's name, verbatim
Description"Development project for feature: {feature name}"
Statusactive
OwnerThe user who clicked the button
ColourFeature's product colour (falls back to #4ECDC4)

The feature is then updated in two ways:

  1. project_id is set to the new project's ID so you can jump between them.

  2. status is flipped to in_development.

After the call, you are redirected straight to the new project in the Projects module.

When the button appears: only when the feature's status is not shipped or wont_do and no project is already linked. Once a project has been created, the Feature detail page shows a "View linked project" link instead.

Required permission: pm.edit on the feature and projects.create on the user, because the endpoint creates a record in the Projects module. The new project is created directly as the calling user's owned project.

When to use dev handoff vs creating a project manually

  • Use the handoff button when the feature is the whole scope of the project (a typical 1:1 feature-to-project mapping). The back-link lets you trace engineering work to the PM spec.

  • Create the project manually (via the Projects module) when the project is bigger than one feature, e.g. "Stripe parity" spanning ten features. In that case, just link the features to the initiative and keep the engineering project separate.

Pagination

The backlog is paginated 50 features per page, ordered by RICE score descending (the ordering and pagination are both done in SQL). Use the page controls at the bottom of the table to move between pages. If your backlog grows very large, the product filter or the /pm/features list narrows it further.