A developer estimates 4 hours on a ticket. QA adds 2 more. Someone has to combine those numbers and type them into Jira's Original Estimate field — and now the ticket says "6h," with no record of whose 4 and whose 2 that actually is.
If that sounds familiar, you're not alone — most teams run into this the moment more than one person needs to add to the same estimate. Here's how teams typically work around it, and where each workaround falls short.
The workarounds teams try
Mental math. Someone adds their number to whatever's already in the field. It works fine until someone forgets to add, adds twice, or the running total quietly drifts from reality over a few sprints.
Splitting into sub-tasks per specialist. Instead of sharing one ticket, teams create a Dev sub-task, a QA sub-task, a Design sub-task — each with its own estimate. It solves the immediate problem, but it comes at a cost: the backlog fills up with tickets that only exist to hold a number, and anyone looking at the parent ticket still can't see the full picture without opening every child.
Leaving a comment. Someone writes "Dev: 4h, QA: 2h" in a comment instead of touching the estimate field at all. It preserves the breakdown as text, but it's not data — it can't be summed, filtered, or pulled into a report. Anyone who wants the real total still has to open the ticket and read the comments by hand, and the field itself keeps drifting further from what the team actually agreed.
The risks that show up later, not right away
Overwriting. Original Estimate is a single value. The last person to edit it wins — there's no merge, no warning. If two people update it around the same time, one contribution silently disappears.
The blind spot in reporting. Even when the math is done carefully and the total is correct, there's no built-in breakdown of whose portion is whose. The History tab shows each raw edit — Dev changed it from 0 to 6, QA changed it from 6 to 8 — but reconstructing who contributed what still means doing that math yourself, ticket by ticket. This isn't about time already logged — Jira, and standard TeamTime reporting, have always tracked time spent per person through work logs. The gap is specifically in the estimate: it only ever exists as one combined number, entered by whoever typed it last, with no record of who it actually belongs to, and no useful way to match a specific person's estimate with their worklog.
This isn't user error — it's how the field was designed
Original Estimate was built to answer "how long will this take," from one person, in one edit. It has no concept of multiple contributors — the field was simply never meant to hold more than a single number. That's a reasonable design for a ticket with one owner. It stops being reasonable the moment a ticket has three.
This gap is well known enough that an entire category of third-party Jira apps exists just to add some form of per-person time or estimate tracking on top of native Jira — which is a decent signal that "one field, one number" doesn't match how most teams actually work once more than one person touches a ticket.
What an actual fix looks like
The fix isn't a better way to do mental math — it's a different data model: an entry per person, per estimate, timestamped, attributable, and editable without wiping out anyone else's contribution — just like the worklog. The total is then calculated from those entries, not typed in by whoever remembered to do the addition last.
Practically, that means a ticket needs:
- A way to include everyone contributing to the estimate, even if only one of them is the actual Jira assignee
- A record of who added what and when
- A total that updates itself instead of relying on someone doing the sum correctly
Where this leaves TeamTime
This is exactly the gap CumulativePlus, a calculation mode in TeamTime's Advanced Tier, was built to close — letting each contributor log their own estimate on a shared ticket, with a full log of who added what and when, instead of one field and a guess.
Each contributor's estimate flows straight into the report — broken down by user, not just totaled.
You can find TeamTime on the Atlassian Marketplace if you'd like to see it for yourself.
