Time in Status: The Number That Shows Where Your Process Gets Stuck

The project ran late. In the meeting, everyone points to a different reason: the client took too long, the team is small, the requirements changed. They all have a bit of a point, and nobody has a number. A blown deadline is a symptom. The cause is somewhere else: in the time each task spent stalled, waiting, at each stage along the way.

That number has a name, time in status, and it's what lets you swap an opinion debate for a conversation about data. Here's what it is, why to use the median and P85 instead of the average, what flow efficiency is and how to find the bottleneck, with a worked example.

What time in status is

Every task goes through stages: "To do", "In progress", "In review", "Waiting on client", "Completed". Time in status is how long it spent in each one. Add them all up and you have the complete cycle, from start to finish.

To measure it, you have to keep every status change, with date and time. Without that history, the only information available is where the task is now, never where it's been. That's why most spreadsheets can't answer the question: they store the current state, not the trajectory.

Lead time and cycle time

Two terms always come up in this conversation. Lead time is the time from when the request was made until delivery, the requester's view. Cycle time is the time from when work started until it finished, the view of whoever does the work. Time in status breaks both into pieces so you can see which one is inflated.

Why median and P85, not the average

Imagine ten review tasks. Nine took 1 day. One was forgotten for 40 days. The average is 5 days, a number that describes none of them. The median, the middle value, is 1 day, and it shows the team's normal behavior. The 40-day task deserves attention, but as an exception, not as a benchmark.

P85 completes the picture. It says: "85% of tasks leave this stage within X days". It's the number you can promise. If review's P85 is 3 days, you can tell a client "review takes up to 3 days" and be right in 85 out of 100 cases, which is far more honest than quoting the average.

Measure	Answers	When to use
Average	How much, adding it all up and dividing	Rarely: a single forgotten task distorts it
Median	How long a typical task takes	To understand normal behavior
P85	How long almost every task takes	To promise deadlines and to spot what's out of the ordinary

A caution: with few tasks, any percentile is fragile. Five tasks aren't a sample. Good practice is to distrust conclusions drawn from a handful of cases and wait for the volume to grow before changing the process.

Flow efficiency: how much of the time is work

Here's a calculation that tends to surprise people. Add up the time the task was actually being worked on and divide by the total cycle. The result is flow efficiency. The rest is waiting: waiting for approval, waiting for someone to unblock it, sitting in a queue.

For a task that took 10 days in total and had 2 days of actual work, efficiency is 20%. The other 80% was waiting. That changes the remedy: hiring more people speeds up the work, but only attacks 20% of the problem. Reducing the waiting, with fewer approval queues and fewer stalled stages, attacks the 80%.

For the calculation to make sense, the system needs to know which of your statuses are work and which are waiting. In Tasskee this comes from your own statuses, with nothing separate to configure.

How to find the bottleneck

A bottleneck is the stage where work piles up, and it's where any improvement pays off the most. To find it, follow three steps.

1. List the stages in the order they happen and note each one's median.
2. Calculate each stage's share of the total cycle. Divide the stage's median by the sum of the medians.
3. Look at the biggest share and its P85. A long stage with a P85 far above its median is the strongest candidate: it's slow and unpredictable at the same time.

An example with numbers

An agency tracks the blog posts it produces for clients. Across 40 completed posts, the medians by stage were these.

Stage	Median	P85	Share of cycle
Topic planning	1 day	2 days	8%
Writing	3 days	5 days	25%
Internal review	1 day	2 days	8%
Waiting on client approval	6 days	14 days	51%
Publishing	1 day	1 day	8%

The medians add up to 12 days. The team was convinced the problem was writing, the stage that takes up the most people's time. The numbers say otherwise: half the cycle is waiting for the client, and the 14-day P85 shows that, in some cases, it's much worse.

The most effective action, then, isn't writing faster. It's agreeing on a response deadline with the client, reminding them automatically and putting approval somewhere easy, like the guest portal. If the median approval time drops from 6 to 3 days, the cycle goes from 12 to 9, a bigger gain than any writing tweak could achieve.

What to look at beyond the bottleneck

Loops and rework

A task that goes back to review three times passed through that stage three times. The right approach is to count each pass, not just the last one. If review shows up with many passes per task, the problem may be in the previous stage: the briefing or the definition of done isn't clear.

What's about to blow up

Comparing open tasks against a fixed deadline that's the same for all of them is unfair: a stage that normally takes a day and another that takes a week can't have the same alarm. The most useful approach is to compare each open task with the normal time for its own stage. A task that's been 5 days in a stage with a 1-day median deserves attention today, without waiting for the project deadline.

Tasks and tickets together or separate

A support ticket and a project task have different rhythms. Mixing the two hides the behavior of each. Measure them separately and then together, if you need an overall view of the team.

Common mistakes when measuring

• Too many or too few statuses. With two statuses, "Open" and "Closed", there's nothing to measure. With twenty, nobody updates them. Between five and eight is usually enough.
• Moving everything at the end of the week. If the team only updates the board on Friday, time in status turns into noise. The measurement is only as good as the discipline of moving the task when it changes phase.
• Using the number to hold people accountable. The goal is to see the process. When it becomes an individual ranking, people start hiding what got stuck.
• Drawing conclusions from a small sample. Wait until you have volume before reorganizing the team.

Where this shows up in reports

Time in status is one of the numbers worth seeing alongside the project's other reports and dashboards: workload per person, overdue tasks, hours. Each one answers a different question. Delay says something went off plan; workload says who's overloaded; time in status says at which stage work is being lost. On its own, none of them tells the whole story, but time in status is usually the one that explains the other two.

How to start

1. Review the statuses on your Kanban board: each one should represent a real phase, and you need to know which are work and which are waiting.
2. Use the board normally for a few weeks, moving tasks as they change.
3. Open the dashboard and look at the median and P85 by stage. Find the biggest share.
4. Choose a single stage to improve, change one rule (item limit, response deadline, definition of done) and measure again the following month.

The payoff from seeing time in status isn't a nice-looking number. It's no longer arguing about where the process gets stuck and starting to decide what to change first, with the data beside you.