Forecasting delivery

The Delivery Forecast dashboard answers three questions from the tracker's issues and the commits linked to them: how fast tasks close per head, whether the backlog is draining, and when. This page is what each panel assumes.

Tasks are tracker issues, and an issue is attributed through its commits

Everything on the page counts issues from the connected tracker — Linear, Jira, or whatever DevLake collects. An issue is assisted when at least one commit linked to it carries an assisted attribution. An issue is attributed to the people whose commits are linked to it, and through them to their teams. An issue with committers on two teams counts for both — attribution, not division.

That linkage needs the issue key in the commit message. An issue with no linked commit is not on the page at all. A team that does not write keys into commit messages sees fewer issues here than it closed, and the tooltips say so.

Throughput per head is the honest form of "nX faster"

Issues closed per week rises when a team grows. Issues closed per person-week — closures divided by the number of people who committed that week, summed over the weeks — takes headcount out, so a team that doubled does not read as twice as productive. The throughput multiple on the page is that figure after adoption divided by the same before it, and it blanks below ten issues on either side.

It is a difference between two periods, not an effect of the tool. Team size, work mix and the release calendar changed too.

The backlog drains only on net flow

Open backlog is everything opened minus everything closed, to date. It shrinks in a week only when closing outran opening in that week. A team can close a record number of issues in a week the backlog still grows, so every forecast on the page uses net flow — closed minus opened — and never throughput alone.

The drain table shows the current backlog divided by net flow under three closing rates: what the team did before adoption, the last eight weeks, and its best recent four weeks. "Never at this rate" means issues arrive faster than that rate closes them, and it is the correct answer far more often than a date is. The burn-up chart draws the same thing: cumulative opened and closed, each continued at its recent rate as a dashed line, and where the dashed lines meet is the drain date. If they do not meet inside 26 weeks, the backlog is not draining at current rates.

Per team, drain needs assignees. Open work has no commits yet, so it cannot be attributed through them; the per-team drain table uses the tracker's assignee instead. Where assignees are empty — most issues, on many trackers — the table carries an (unassigned) row for every open issue with nobody on it. That row is the honest size of what cannot be forecast per team until the tracker assigns work.

What the forecast assumes

That issues keep arriving at the recent eight-week rate and close at the chosen rate, every week, with no holidays, incidents or scope changes. A drain date is the date under those assumptions, not a commitment.

Issues are counted, not sized. Fifty small ones and five large ones look alike here.

Productivity per task

For closed issues with linked commits, the page averages per task: commits, lines, person-days of committing, and hours from opened to resolved — split by whether any linked commit was assisted. Tasks per person-day is the throughput form. Both sides need five tasks; the difference is between self-selected cohorts and is not an effect. The reasoning behind that caveat is in Measuring productivity.

Filters

The team and contributor filters apply to every panel attributed through commits — per team, per person, per task. The org-level backlog and burn-up stay whole on purpose: an open issue carries no person until the tracker assigns it, so filtering them by team would silently drop most of the backlog. The dashboard's opening text says which panels the filters reach.