While Jira natively allows you to track Original Estimates and Logged Work on individual issues, it lacks a built-in way to automatically aggregate that data up the hierarchy.
Cumulative Mode automatically summarizes the data from every child work item and combines it with the parent’s own data to give you a single, accurate health check of a high-level task or container.
Why use Cumulative Mode?
In a standard Jira setup, a parent issue (like an Epic or a Task with sub-tasks) only shows its own time tracking. If the parent has ten child issues, you would have to manually add up the estimates and hours logged for all ten to see the true progress.
TeamTime’s Cumulative mode does the math for you. This is especially useful when:
-
Project scope changes frequently.
-
New sub-tasks are added mid-sprint.
-
You need to see the total effort of a feature, not just a single ticket.
A typical example is a delivery or development project.
For example, a team may start with a high-level task such as Feature Development, and then break it down into smaller parts:
-
Requirements Gathering
-
Analysis
-
Development
-
Testing
Each of these issues may then be broken down further into subtasks or implementation tasks. In cumulative mode, TeamTime sums up the estimates and logged time across the full hierarchy, so the final total reflects the combined effort of all issues below.
This mode is useful when you want to see the full amount of work related to a feature, epic, or larger piece of delivery, including everything that was done at lower levels.
How the logic works
In cumulative mode, the parent work item itself is also included in the total if it has its own estimate or logged time.
That means the calculation does not only include child items — it includes the work item you are looking at as well.
Whether you are viewing the TeamTime panel inside an issue or generating a high-level report, the app calculates the following:
|
Metric |
Calculation Logic |
|---|---|
|
Estimate |
Parent estimate + Sum of all child work item estimates. |
|
Time Spent |
Parent worklogs + Sum of all child work item worklogs. |
|
Remaining |
Estimate − Time Spent |
|
Ratio |
0% means work hasn't started or no hours have been logged yet. 100% means the hours logged exactly match your original estimate. Over 100% means the work has taken longer than originally estimated. |
Understanding double counting
Because the parent issue is included in the total, cumulative mode can lead to double counting if estimates are entered both on the parent issue and on its child issues.
Example:
-
Parent work item: Analysis — 10h
-
Child issues:
-
FE Analysis — 3h
-
BE Analysis — 3h
-
Integration Analysis — 3h;
In this case, the total becomes:
-
10h + 3h + 3h + 3h = 19h
This may be incorrect if the original 10h estimate on the parent work item already included the work that was later split into child issues.
How to avoid double counting
To keep totals accurate in cumulative mode, it is recommended to use one of these approaches consistently:
-
Keep the estimate only on the child work items, and reduce the parent estimate to 0h or a small coordination value;
or -
Keep the estimate only on the parent issue, and use child work items for structure without estimates.
Cumulative mode does not try to guess which estimation model you intended to use. It simply sums all estimates and logged time in the hierarchy, including the current work item.