Why is the time in stage a median and not an average?

Because one outlier moves an average by days. The median is what a typical task experienced, and it is the same statistic the risk score uses to estimate remaining work.

Does a task that is still in a stage count?

Yes. Its open interval is counted up to the moment of the query, so stuck work shows up in the number instead of being hidden until it finishes.

Why does one stage appear once when I have twenty projects?

Intervals are grouped by the stage key from the template, not by the per-project stage row, so the same stage across all projects is one line.

What window does the view use?

The window you choose on the analytics screen. Minutes are clipped to it, so only the part of an interval inside the window is counted.

Finding the bottleneck: median time in stage

The bottleneck in a workflow is the stage with the longest median time, measured from the moment tasks enter it to the moment they leave. Tasked records that interval for every task and every stage, groups it by stage name across all your projects, and shows the median inside the window you choose. It does not credit a whole job's time to whichever stage it happened to be in when it finished.

Published September 15, 20265 min read

The wrong number, and why it looks right

The easy way to measure a stage is to take each finished task, look at the stage it was in when it finished, and charge the task's whole duration to that stage. The number comes out large, it sorts nicely, and it is wrong: it says the last stage is slow because every task finishes there. A job that sat two weeks waiting for a script and one hour in Delivery is counted as a slow Delivery.

Tasked's own first bottleneck number worked this way, and the product's plan names it as the thing to fix before anything else in analytics could be trusted. The fix is not a better formula over the same data. It is different data.

What an interval is

Each time a task enters a stage, Tasked opens an interval with the task, the project, the stage and the moment of entry. Each time the task leaves, it closes that interval and opens the next one. The write happens in the same transaction as the move, so there is no sweep that can fall behind and no move without its interval.

A task sent back to the stage it is already in starts a new interval; a self-transition is a real move. A task that is still in a stage has an open interval, and the metric counts it up to the moment of the query. Finished work and stuck work are both in the number.

The interval also remembers the SLA hours that were in force when it was opened. Changing an SLA later does not restate what happened under the old one.

Why the median and not the mean

One task that waited three weeks on a client moves a mean by days and a median by nothing. The median is the time in stage that a typical task actually experienced, and it is the number the risk score also uses to estimate remaining work. Using the same statistic in both places means the bottleneck you see and the risk you are warned about come from one view of the same history.

The API field that carries the number is still named as a mean for compatibility with earlier clients; the value in it is the median.

What the bottleneck view shows

For every stage name that had at least one interval touching the window, the view lists the median minutes in stage, the number of tasks that left the stage inside the window, how many are open in it now, and how many distinct days had activity. For approval stages it also totals the minutes spent waiting on a client. Stages are sorted slowest first.

Minutes are clipped to the window. A task that entered a stage before the window and left inside it contributes only the part that falls inside, so a 30-day view is a 30-day view even for work that started earlier.

Median minutes in stage, from intervals.
Throughput: intervals that closed inside the window.
Open count: intervals still running.
Days measured, so a stage with one busy day is not mistaken for a trend.
Waiting on client, on approval stages only.

Reading it across projects

Every project carries its own copy of the workflow, so Client Review on project A and Client Review on project B are two different stage rows. The bottleneck view groups by the stage key, the name the template gave it, so those two rows are one line. That is what turns twenty boards into one answer about your process rather than twenty answers about your projects.

If two templates use the same key for stages that mean different things, they will share a line. Keep the keys honest in the templates and the view stays honest.

From bottleneck to fix

A slow stage is either under-resourced, under-defined or waiting on someone outside the team. The load tab tells you the first, the waiting-on-client total tells you the third, and the process audit tells you the second: it compares the median you just read against the SLA hours you set on that stage, counts the breaches, and proposes a correction it has simulated over your recent history.

The order matters. Read the median first, then decide whether the SLA is wrong or the work is.

Questions that keep coming up

Why is the time in stage a median and not an average?: Because one outlier moves an average by days. The median is what a typical task experienced, and it is the same statistic the risk score uses to estimate remaining work.
Does a task that is still in a stage count?: Yes. Its open interval is counted up to the moment of the query, so stuck work shows up in the number instead of being hidden until it finishes.
Why does one stage appear once when I have twenty projects?: Intervals are grouped by the stage key from the template, not by the per-project stage row, so the same stage across all projects is one line.
What window does the view use?: The window you choose on the analytics screen. Minutes are clipped to it, so only the part of an interval inside the window is counted.