Workload View to reflect time remaining
Skip Lefever
Reduce hours already completed toward estimate, so that the remaining total reflects what is actually left to complete for each day.
Log In
Vasil Enchev
I’m leaving here an AI-generated mockup of the remaining time, which is also deducted from the capacity. This isn’t a design that will be implemented in ClickUp, but I wanted to get some feedback on the direction if that’s the right one.
The idea is that if you have a task estimated to take 20 hours over 5 days, represented as [4, 4, 4, 4, 4], and you’ve tracked 16 hours instead of 12, assuming now is day 3 - what is shown and calculated in the workload is [5.3, 5.3, 5.3, 2, 2]. - On days 4 and 5, you have less time to complete your tasks than you would have without any time tracking.
One open question this raises is what if you don’t track time at all? In that case, we assume you worked the specified time and don’t do anything with the hours. The opposite scenario would be to simply push all time towards the last two days.
Dan Heuer
I dont think that showning the time remaining on task is much of help (we can use formula for that). Getting the time remaining to the workload is critical
Vasil Enchev
Dan Heuer: I meant on timeline / workload items (tasks)
Vasil Enchev
Hey Y'all I merged a lot of posts together to get some critical mass for this. Let's get some new feedback in here for 2026.
The way I understand it there are both requests for tracked time to be reflected next to the daily capacity as well as on tasks so that you get time remaining.
Would something simple as just showing 27h/24h on tasks be a solution or a good first step?
Hovering on that could show more info like Time remaining. Show everything on the task is a bit complicated but we have efforts to do proper fields on tasks for timeline and workload.Piotr Sybilski
Vasil Enchev It would be great to have an option to see in the workload values showing time left (estimate-time tracked) as the workload for the future (i.e. time after today). Time in the past could spread the time already tracked evenly. We use it not to create unhealty overload for employees in the coming weeks/months. With current approach workload view does not take into account what really happened (i.e. uneqal work time, someone worked on the task for a week straight and is close to finish or someone had other obligations and did not put a single hour into task, both will show the same workload for the next week).
Vasil Enchev
Piotr Sybilski Yeah, that would be great, but it’s a bit more complex. Have anyone seen anyone who is doing it? As soon as we do that it would be natural to start moving end dates on the timeline (finish early, finish late)
Ryan Tirrell
PLEASE MAKE THIS A THING!
I am managing workload across teams of 20-30, reducing the time remaining by time worked would be an absolute game-changer!
Keep the [Original Time Estimate] field.
Add a [Time Remaining] field, which inherits the [Original Time Estimate] when its first added.
Then when [Actual Time] is recorded against the task, reduce the [Time Remaining] by the amount worked. When it runs over, show a negative figure.
Icing on top would be:
- When in negative show an optional highlight (i.e., amber/red)
- Optionally prevent adding more time than the original estimate (great for billing clients based on fixed price / hours work).
Vasil Enchev
Ryan Tirrell: Thank you for this feedback, would 25h/16h work for you? I'm trying to. grasp how important is seeing the remaining time as a separate field [-9h] [16h]
I guess also when remaingin time is equal to the estimate (nothing tracked) we just don't show it? [16h] [16h] would look odd to me.
Ryan Tirrell
Vasil Enchev - saw your mockup image above.
Yes that looks great for the workload view task items.
Just remember, the other - arguably most important - point would be that the [Time Remaining] should be the field used to calculate against capacity. So as users add [Actual Time] to their tasks, their real capacity is reflected in the Workload View.
I will just reiterate that having those fields be separate on the list view is important, because we might want to order by [Time Remaining] to understand where the quick-wins are - or the things that haven't been worked on at all (full time remaining).
Vasil Enchev
This is also related to having a time remaining field -> https://feedback.clickup.com/feature-requests/p/add-time-remaining-column - and being able to see any fields in the workload view -> https://feedback.clickup.com/feature-requests/p/fields-support-for-timeline-workload
Vasil Enchev
Merged in a post:
For Workload view, take into account tracked time in time estimates or allow time to be split into multiple periods
J
Jan
Right now, the workload view only seems to take into account time estimates. When a task has tracked time, the workload view doesn't take this into account and won't shorten the time estimate of the task.
Clickup's Workload view also assumes that task time will be equally distributed per day. This is an issue for tasks that are worked on inconsistently. In some cases, I only have thirty minutes for a task one day and an hour for it the next day.
There isn't a good way to split up the time estimates in Workload view other than by artificially splitting the task into subtasks and tracking hours that way.
Vasil Enchev
Merged in a post:
Time Tracked decucted from Time Estimated in Workload View
Robin Bevilacqua
We're using the Workload View for Resource Management but we've encountered a problem when it comes to Time Tracked and how it impacts this view.
If someone is assigned to work on a task for which we've estimated 8h, and that person tracks 6h against it, it would still show 8h in the Workload View rather than the 2h remaining, do you know if this is something that can be adjusted?
Vasil Enchev
Merged in a post:
Estimated Time Minus Tracked Time
John Wylde
As you can see in the images, this particular job only has 1h worth of work remaining on the task but when viewing in the workload overview it uses the full 8.5h for calculation
It would be amazing if it took into account the tracked vs estimate and adjusted workload accordingly
Vasil Enchev
Merged in a post:
time tracked in workload
jen
Hi can you please add time tracked in workload. Workload was the initial time estimate. but if a project takes more time than the estimate. The workload should increase too. Thanks
Vasil Enchev
Merged in a post:
Dynamic Workload Calculation based on "Time Remaining" (Net Effort)
James Nollman
The Problem: Currently, the Workload View calculates user capacity based solely on the Time Estimate field (Gross Effort).
This creates a critical failure for Agile teams handling Sprint Rollovers:
We have a task estimated at 10 hours.
A developer logs 8 hours in Sprint A but does not finish.
We move the task to Sprint B.
The Error: ClickUp’s Workload View for Sprint B blocks out 10 hours of capacity for that developer, even though they only have 2 hours of work left.
The Current Workaround (And why it fails): To fix the capacity chart, we have to manually change the Time Estimate from 10h to 2h.
The Consequence: This destroys our reporting. We lose the historical record that the task was originally 10 hours, which breaks our Billing Rollups, Velocity Reports, and Estimating Accuracy analysis.
The Proposed Solution: In the Workload View Settings (under "Capacity"), please add a toggle for "Calculation Method."
Option A: Total Estimate (Current behavior - Best for Waterfall/Fixed Scope).
Option B: Time Remaining (New behavior - Best for Agile/Sprints).
Logic: Time Estimate minus Time Tracked = Capacity Reserved.
Competitive Context: Azure DevOps (ADO) and Jira handle this natively via the "Remaining Work" field. For agencies moving to ClickUp, this is the single biggest blocker to accurate capacity planning without destroying historical billing data.
Impact: This would allow teams to keep their Billing/Sales data accurate (Total Estimate) while keeping their Resource Planning accurate (Remaining Effort) without manual double-entry.
Load More
→