Orangescrum
Documentation index for AI agents (llms.txt). A markdown version of this page is available at /task-duration-optimization.md or by requesting this URL with the header Accept: text/markdown.
Planning technique

Task Duration Optimisation, Explained Properly

Most tasks do not run long because people worked slowly. They run long because they were waiting, or because the task was never one task. Here is how to fix that, and what Orangescrum records while you do.

Start free trial See all features

What is task duration optimisation?

Task duration optimisation means reducing how long a piece of work takes from start to finish, and making the number you plan with match reality. There are two separate figures involved. Effort is the hours somebody actually spends. Duration is the elapsed time from start to done, which includes waiting for a review, an approval, an environment, or an answer. In most teams duration is far larger than effort, so the gains come from removing the waiting and from breaking work down until it can no longer hide. Orangescrum holds the estimate and the logged time on each task, so the gap between the two is measurable rather than remembered.

Why durations are always wrong

  • Effort and elapsed time are treated as the same numberA task is estimated at six hours and scheduled to take a day. It takes four days, because three of them were spent waiting for a review that nobody had booked.
  • The task is too big to estimateAnything estimated at two weeks is really several tasks with an unknown one hiding among them. Large estimates are usually a sign the work has not been understood yet.
  • Padding is invisible and compoundingEveryone quietly adds a safety margin, then uses it, because work expands to fill the time allowed. The buffer is spent whether it was needed or not.
  • Nobody looks back at the estimateThe task closes and the difference between six estimated hours and nineteen logged ones is never discussed, so the next estimate for the same kind of work is exactly as wrong.

What Orangescrum actually gives you

Real features, named. Nothing here is an algorithm that decides for you.

Hold an estimate on the taskEvery task can carry estimated hours, so the plan has a number in it rather than an assumption in somebody's head.Task managementLog what it really tookTime is logged against the task by timer or entry, which gives you the actual figure to compare the estimate against.Time trackingCompare estimated with actualReports put planned hours next to logged hours, so a pattern of underestimating a particular kind of work becomes visible instead of anecdotal.ReportingBreak work down until it is knowableSubtasks and checklists split a vague task into steps somebody can actually estimate, which is the single most reliable way to improve a duration.Checklists and subtasksMake the waiting visibleCustom statuses let you name the states where work sits idle, such as waiting for review or blocked, so queue time shows up as a stage rather than disappearing into In Progress.Custom status workflowSee who is too loaded to be quickA person with six concurrent tasks finishes all of them slowly. A workload view shows that before you wonder why durations slipped.Workload management

How to make durations honest

  1. Separate effort from elapsed timeWrite down the hours of work and the expected wall clock time as two different numbers. The difference is your queue time, and it is usually the bigger of the two.
  2. Split anything you cannot pictureIf nobody can describe the finished task in a sentence, it is not one task. Break it down until each piece has an obvious first step and an obvious end.
  3. Name the waiting statesAdd statuses for review, approval, and blocked. Once a task can sit in a named queue, you can count how long it sat there, and queue time is usually the cheapest thing to remove.
  4. Estimate as a team, brieflyTwo people estimating the same task out loud for a minute beats one person estimating carefully for ten, because most estimation error is missing information rather than arithmetic.
  5. Close the loop on the numbersOnce a month, look at estimated against logged for a category of work and adjust how you estimate that category. This is the whole discipline. Everything else is detail.

What Orangescrum does not do here

Orangescrum does not estimate for you and it does not optimise a duration. There is no model that learns from your history, no automatic adjustment of estimates, no PERT or three point calculation, no Monte Carlo simulation, and no AI that predicts how long a task will take. It stores the estimate you enter, records the time your team logs, and reports the difference. It also does not measure queue time as a built in metric. If you want to know how long work waits in review, you have to model that as a status and look at how long tasks stay in it. The judgement about how long something should take stays with the people doing it.

Task duration optimisation <em>FAQ</em>

Does Orangescrum automatically estimate or shorten task durations?
No. Orangescrum does not predict durations, adjust your estimates, or shorten anything on its own. There is no estimation model and no forecasting engine. It holds the estimate you enter and the hours your team logs, and shows you the gap so you can correct the next estimate yourself.
What is the difference between effort and duration?
Effort is the hours of actual work. Duration is the elapsed time from start to finish, which includes every hour the task spent waiting. A task can be four hours of effort and five days of duration. Confusing the two is the most common reason plans are optimistic.
How do I find out where the time really goes?
Log time against tasks so you know the effort, and use custom statuses to name the waiting states so you can see how long work sits idle. Comparing logged hours with elapsed calendar time on the same task usually makes the answer uncomfortable and obvious.
Does Orangescrum track how long a task sits in one status?
There is no dedicated time in status metric. What you can do is model the waiting explicitly as its own status and review the board and task history. Teams that care about this closely tend to check it in a weekly review rather than expect a report.
How small should a task be?
Small enough that somebody can describe the finished result in a sentence, and short enough that it moves within a few days. Anything longer hides an unknown, and the unknown is what makes the estimate wrong rather than the arithmetic.
Which plan do I need for this?
Tasks, subtasks, checklists, and custom statuses are available across the paid Cloud plans and included in Self-Hosted. Time tracking and timesheets are on Cloud Pro and above and included in Self-Hosted. Planned against actual reporting comes with the reporting module.
Should I pad estimates to be safe?
Padding each task individually tends to be wasted, because the margin gets used whether it was needed or not. It is usually better to estimate honestly and hold one buffer at the project or milestone level, where it can absorb the tasks that genuinely go wrong.

Put a real number on the work

Free 14 day trial, no credit card. Every plan includes unlimited users.

Start free trial

Related

Time trackingWhat the work actually tookCritical path optimisationShortening the chain that sets the dateCost-efficient task sequencingOrdering work so it wastes lessWorkload managementWhy loaded people finish slowly