Jira Plans roll-ups help explain planned work across a hierarchy. A time report explains recorded effort and, where maintained, the forecast against a baseline. A number displayed on a parent can be useful in either context, but you need to know what it represents before using it in a stakeholder update.
Start with the question. “When might the initiative finish?” and “How many hours have we used?” require different evidence, even when both answers appear near the same epic.
What a Plans roll-up represents
Atlassian documents advanced Plans roll-ups for Jira Cloud Premium and Enterprise. A plan can infer parent values from children, including dates and estimation-related values. Its documentation also distinguishes calculated planning dates from dates saved back to Jira work items. Plans roll-up documentation.
Review the estimate roll-up rules for your configured estimation unit and hierarchy. Atlassian describes time-based rolled-up estimates as reflecting remaining work and decreasing as time is logged on children. Plans therefore already uses time-related information in this workflow. A calculated remaining value still should not be treated as a historical approved budget or a total of past worklogs.
Compare the decisions, not the labels
| Decision | Evidence to inspect | Appropriate starting view |
|---|---|---|
| Schedule a workstream | Scope, estimates, dependencies, dates, and planning assumptions | A plan |
| Understand recorded effort | Included issues and worklogs | A time report |
| Forecast effort at completion | Logged effort plus current remaining estimates | An effort forecast |
| Explain variance from approval | Preserved baseline and scope changes | A baseline comparison |
| Approve billable hours | Period entries, billing rules, and approval record | A timesheet or billing process |
These views can support each other. The mistake is assigning a meaning to a number that its source does not support.
A synthetic example with two correct answers
An initiative contains two epics. The planning team estimates them at 13 and eight story points. A planning roll-up of those agreed values is 21 points.
Separately, included Jira worklogs contain 26 hours for one workstream and 14 hours for the other: 40 hours recorded. That does not imply a conversion rate between points and hours. The two totals use different units for different purposes.
If the team also maintains a separate 50-hour effort baseline and expects 18 hours remaining, its effort forecast is 58 hours, eight above that baseline.
Planning estimate: 13 + 8 = 21 story points Recorded effort: 26 + 14 = 40 hours Effort forecast: 40 + 18 = 58 hours Variance against the separate effort baseline: 58 − 50 = +8 hours
Every value in this example is invented for explanation. A real report must establish that the issue scopes align before placing these figures alongside each other.
Check four boundaries when the totals disagree
1. Included work
Compare the actual issue keys. A plan may include a broader hierarchy than the project or saved filter used by a time report. Exclusions, archived work, or missing access can change what appears.
2. Unit and estimation level
Identify whether the values are hours, days, points, or counts. Then check whether estimates live on parents, children, or both. A time unit also needs a consistent conversion if your export contains seconds or configured working days.
3. Stored value versus calculated value
Inspect whether the parent displays its own field or an inferred total. Adding an aggregate to its contributing children counts the same information twice. Treat the aggregate as a presentation result until you understand its source rule.
4. Snapshot and update timing
Record when each view was captured and whether proposed planning changes had been saved. Comparing yesterday's export with today's edited plan can produce a real difference without a reporting defect.
Use a small reconciliation before a larger rollout
Choose a parent and two children with values you can inspect individually. Write the expected scope and totals on paper. Compare the planning view, Jira source fields, and the proposed time report.
Then add an edge case: a missing estimate, genuine direct parent work, or a child outside the selected scope. Record how the output changes. This exercise reveals the calculation rule more reliably than comparing two unexplained grand totals.
For an effort-focused workflow, TimePillar is an option to evaluate using that known issue set. It should be assessed against your required reporting behavior rather than treated as a substitute for every Plans capability.
Give stakeholders one clear explanation
A useful update identifies the planning view and the effort view explicitly: “The initiative is planned as 21 story points. The agreed effort scope has 40 hours recorded and a current forecast of 58 hours against a 50-hour baseline.”
Only use that wording if your team actually maintains those measures. Do not create a second baseline merely to populate a report.
Continue with the estimated-versus-actual example for variance calculations, or remaining-estimate reporting when the forecast itself needs investigation.