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.