Estimating Tasks and Subtasks

[RJ Lehman]

I have a half scrum half service team that uses Tasks (not user stories although they are lateral) and just started using subtasks. It's messing up metrics. Ideally we would use stories and point but because of contractual reasons we have to use only hours to estimate. 

 I'm thinking the best way would be to only use tasks with checklists and only estimate and put work against the tasks.  This is an anti-pattern, I know but I can't find a better solution that is simple and clean.  

Does anyone have past experience having this problem and how did you solve it? 

[VENKATESWARLU KURUVA]

Hi RJ,

Your instinct is right — Tasks with checklists and hours only at the Task level is the cleanest approach for your situation. It's not really an anti-pattern when contractual constraints require hours over points.

Why subtasks mess up metrics: Jira can double-count time (parent + subtask estimates) and sprint burndowns get skewed depending on how you track.

Recommended approach:

Estimate hours on Tasks only — don't estimate subtasks.

Use checklists or subtasks for breakdown but treat them as progress indicators, not estimable units.

Log work against the parent Task to keep reporting clean.

If you must use subtasks with hours: Configure your board to only show subtasks in the sprint (not parent Tasks), so estimates aren't double-counted in burndown charts.

This keeps it simple, contractually compliant, and your metrics accurate.

[Martin Sturm - JXL]

Hello @RJ Lehman 

This is a common tension, and I do not think your Tasks-with-checklists idea is really an anti-pattern given your hour-only constraint. A couple of things about how Jira handles time on subtasks that are worth knowing before you decide.

On a parent Task, the Time Tracking panel can show an aggregated view. When you turn on "Include sub-tasks", the bar sums the Original Estimate, Remaining Estimate, and Time Logged across the parent plus its subtasks. So the rolled-up hours are visible on the Task even when work is estimated and logged on the subtasks.

The catch is that this aggregation is display only. The parent's own Original Estimate and Remaining Estimate fields are not changed by it, so JQL, gadgets, and most reports read the parent's raw field values, not the sum. That mismatch is usually what makes subtask metrics feel "off."

Two clean ways forward:

• Estimate and log on Tasks only. Keep subtasks (or checklists) purely as a breakdown of steps with no time on them. Reporting then reads cleanly off the Task, and there is no double counting. Checklists are the lighter option since they cannot carry estimates at all.
• Estimate and log on subtasks, then roll up to the parent field. A Jira Automation rule can recalculate the sum of the subtasks' estimates and write it back to the parent's estimate field on change. It is most often demonstrated with story points, but the same pattern works for time fields.

Whichever you pick, the key is to estimate at one level only and be consistent, so nothing is counted twice.

Best, Martin

[Martin Sturm - JXL]

Following up on my earlier answer   if you do want to keep subtasks and have their hours roll up to the parent Task without maintaining an automation rule, that part is also doable with an app.

If you are open to solutions from the Atlassian Marketplace, the app my team and I work on, JXL for Jira, handles this with sum-ups. JXL is a spreadsheet-style view of your issues, and sum-ups aggregate any numeric or time field (Original Estimate, Remaining Estimate, Time Logged) from subtasks up to their parent Task across the hierarchy. The rolled-up hours show on the parent row with no fields to overwrite and no rule to keep in sync.

Because the view is a Sheet, you can also enter and adjust all your hour estimates inline in one place, then read the totals per Task. It is purely a view and reporting layer, so it does not change how Jira stores estimates or how your board behaves.

Disclosure: I work for the team that builds JXL.

Best, Martin

[Olga Cheban _TitanApps_]

Hi, @RJ Lehman 

There's actually a native way to handle this if you want to keep using subtasks. Jira Automation has a rule that rolls up child estimates to the parent: when a child's estimate changes, the rule recalculates the sum and writes it to the parent's estimate field. It's most commonly shown for story points, but the same mechanism works for hours too. So your parent Tasks would end up with an accurate hours total based on what's been estimated on the subtasks.

That said, your idea to use Tasks with checklists is also a valid path. Estimates will stay on the Task level, while checklist items are non-estimable progress indicators, and there's no roll-up logic to maintain.

The piece that usually makes people hesitate with this approach is that Jira's built-in action items are pretty basic. Just plain text lines you tick off. If your "checklist" is supposed to carry real work breakdown, that minimal format does feel like it's missing something.

If you are open to trying out a dedicated marketplace option, I can recommend our solution Smart Checklist for Jira. It allows you to add feature-rich checklists to Jira work items and save them as templates. Each checklist item has its own status (To Do, In Progress, Done, or any custom status you set up), and you can also add an assignee and deadline, links to external documentation, and more. Each checklist item can also have an expandable section with details where you can drop anything you need, from bulleted lists to images. 

With this level of detail on each item, you basically get the same functionality you'd otherwise get from subtasks. Here's what it looks like:

Checklist progress can also be shown on your Jira board, if needed. Each Task card displays a completion percentage based on the checklist. So you get the visibility you'd normally get from subtasks, but without cluttering your board and without the subtask-level estimation mess.

For the service side of the team, the template feature is especially handy. You can save checklists for recurring tasks and common request types as reusable templates and apply them to new Tasks automatically.

I hope that helps!