Sprints, deadlines, capacity, meeting load - the arithmetic behind every status report, typed in one line.
Project math is duration math: what's left of the sprint, how many days to the release, how much capacity the meetings ate. TCalc answers each as a single expression - no spreadsheet, no date-picker forms.
Dates subtract like numbers, durations convert between units, and custom converters can make a "day" mean 8 working hours.
The single most consequential distinction in planning is between effort and duration. Four hundred hours of effort split between two people is two hundred hours each, which is twenty-five working days, which is five calendar weeks - and none of those numbers is interchangeable with the others. Quoting effort where a client expects duration, or the reverse, is how delivery dates become arguments.
Doing the conversion explicitly, in one expression per step, keeps the chain auditable. It also makes it obvious where an assumption is hiding: the eight-hour day and the five-day week are conventions, and if the project runs on different ones the whole chain shifts.
Four hundred hours of effort split across two people.
Two hundred hours as working days per person.
Twenty-five working days from now, as a calendar date.
Every estimate carries contingency, and the difference between a good plan and a padded one is whether the contingency is written down. Adding twenty per cent to an eighty-hour estimate gives ninety-six hours, and stating it that way lets a sponsor argue about the percentage rather than about the total. Hiding the same sixteen hours inside the estimate makes it invisible and therefore unarguable - which feels safer and is worse.
The same applies to schedule buffer. Three sprints plus a week is a different commitment from four sprints, and saying which one you mean is the whole point.
An eighty-hour estimate with an explicit twenty per cent contingency.
Three sprints plus a stated week of buffer.
A quarter as calendar days - roughly six and a half sprints.
Tracking a budget is subtraction, and the useful output is not the remaining hours but the date those hours run out. Two hundred hours less four months of logged time leaves thirty-five hours; at a burn of eight hours a day that is roughly four and a half working days, which converts to a specific calendar date.
That date is what belongs in a status report. Remaining hours are an abstraction a sponsor can nod at without acting on; a date is a deadline, and it prompts a decision while there is still time to make one.
Budget remaining after four months of logged effort.
The remainder expressed as working days at a full-time burn.
A countdown to a fixed milestone date.
Sprint time remaining after work burned so far.
Days until the release date.
Four workshop blocks of capacity.
The real weekly cost of daily stand-ups.
Subtract them: 2026-12-24 − 2026-07-17 = 159 days. TCalc parses dates directly, so countdown math needs no calendar clicking.
Subtract burned time from the sprint length: 14d − 3d 4h = 10D 20h. Save "Sprint = 14D" as a custom button and it's one tap.
Yes - built-in conversion treats a day as 24h, and custom converters let you define 1 day = 8h so 1 week = 40 hours, matching real capacity planning.