Epic and User Stories - Should Time Tracking be used or not?

Question

Hi Jira Community,

I am setting up bespoke field configurations for Epics/User Stories and Tasks/Subtasks.

I am curious should Epics and User Stories have time tracking fields (Original Estimate, Time Logged)? I am under the impressions its the tasks and subtasks where this should be tracked. Epics should have the overall length you think the project will last which should be captured by Start Date and Due Date.

Is this the right way of thinking?

Thanks for your help,

Sarah

DJ_66gn1u · Accepted Answer

Sub-Tasks are within the story,

Story gets the story points.

Time tracking (Original Estimate / Remaining Estimate) gets to the sub-tasks level within the story. (If not sub-tasks are there and just independent story, yes in that case Time Tracking will have to be used at story level)

Lets say there are 2 sub-tasks and the Original Estimate is 2 hours each for them.

In this case at the story level you will see total estimate time as 4 hours.

Team member working on the sub-task uses the "Work Log" hour feature of Jira to enter the time spend on the sub-task.

Whatever time is entered, Jira itself deducts that much time from the Total Remaining Estimate  (means from Sub-Task 1 and Sub-Task 2) and displays it at the story level.

Remaining estimate of individual sub-task can be visible by going into the sub-task Jira ticket.

Snapshot mentioned below is something I have from the story level.

Epic usually gets the T-Shirt Size or a broader estimate in terms of how many sprints will it take to implement the epic.

Emre Toptancı [OBSS] · Accepted Answer

Hello @Sarah Chapman ,

Epics can be used as something like a work package that can span over multiple sprints. Putting planned start or end dates on Epics might make sense but I would say you shouldn't put time estimation and worklogs on them. In most cases, even "planned end date"s do not make sense due to the dynamic nature of Epics. (Jira's Epic Burndown report helps here)

Stories (or any kind of backlog items) should be estimated using Story Points when they are in the backlog. Sprint capacity should also be decided based on story points. Once they are included in the sprint backlog and the sprint starts, you can just keep going with the story points. If you are working with stories large in size but small in number, it might also make sense to time estimate them (within the sprint) and prepare burndown chart based on Remaining Estimate. Jira burndown reports support this. Check your board settings.