Time to Market measures how long a task takes to go from its first appearance on the board to being marked delivered. It's the broadest delivery metric in the flow set: it captures planning, queuing, coding, review and QA together.
What it measures
The elapsed time between a task's first recorded status change and its last one, for the tasks that reached a delivered status inside the period you selected.
How Leanmote calculates it
time_to_market = last_status_change - first_status_change
The clock is the task's own status history. Leanmote does not watch your CI/CD or deployment events for this metric, and does not follow a pull request back to the issue.
That means the finish line is whatever your board calls delivered, not the moment code ran in production. If the team marks Done at merge, TTM ends at merge; if it marks Done after the release, TTM includes the release wait. The number moves with the convention, not just with the delivery.
Tasks with fewer than two status changes are skipped — there's nothing to measure between.
Only tasks that reached a delivered status inside the window are counted. Work still in flight contributes nothing.
Hours can be counted on the raw clock or on working hours, following the organization's setting.
Leanmote computes both the average and the median. Unlike Cycle Time, Lead Time for Changes and the review metrics, Time to Market has no method selector — you can't switch it to a percentile.
How to interpret it
TTM is normally longer than Lead Time for Changes, because it adds the planning and queuing time before code is written.
TTM much larger than Cycle Time means tasks sit in the backlog or "to do" for a long time before work starts. Investigate intake and prioritization.
Stable TTM with rising Cycle Time usually means planning got faster but execution slowed.
Before drawing conclusions from a jump, check whether the board's delivered status changed meaning. Because the finish line is a status, a workflow edit moves this metric without anything about the delivery changing.
What to do about it
Reduce backlog age before adding new ideas. The fastest TTM win is usually pruning, not coding faster.
Slice work earlier so tasks are started sooner after they're created.
Pair it with Cycle Time to see whether TTM is dominated by the wait before work starts or by the work itself.
Related metrics
Lead Time for Changes
Cycle Time
Flow Efficiency