How to present estimated time of a sub-task in a story view (instead of progress in %)

[maayan]

We're using agile -scrum and giving time estimates per story using sub-tasks. (i.e. Story is the parent of subtask).

I'm looking to view the time estimates of subtasks in the stories in the same way I see in the backlog: 

This is how it shows in the story: 
the time estimate is shown in % instead of the time estimate itself  

This is how it looks in the backlog:
This is the desired way- shown as time (1d /6h etc. ) and not % of progress 

Do you know how I can fix it? 

[Krishna Shrestha]

I am in the same position as @maayan  was in 2019. I just need to know what time it takes to complete the subtask in the list itself. otherwise, I have to go to detail of each task which make planning more time consuming. 

I read through all the conversation, and I agree with @maayan

We use Jira for project management and tracking reporting purpose as well. My question here is how we know if team has estimated one of six subtasks from the list [example]. Yes, we can do that by going in detail of each task, but we want to be more effective. 

@Nic Brough -Adaptavist- Do you have any different thought process here in 2024?

[Vilmos Varszegi]

Hi @maayan where did you adjust the configuration so that the estimated time in hours is displayed in your overview?
Unfortunately, they are not displayed for me although I have entered the estimated time at subtask level.

[Nic Brough -Adaptavist-]

The estimates on sub-tasks do not matter in Scrum, so Jira does not display them.  There's nothing here to "fix", as Atlassian have gone with the most simple approach of not displaying them at all.

[maayan]

Thanks, Nic for your answer, however, it seems strange a couple of reasons: 

1. I can see it in the backlog view - so I guess they had and saw the value for it there
2. With time estimates you can accumulate the time estimates of a sub-tasks to the story (out of the box feature so they do matter). 
This total time estimate in the sub-task level is how much working time the story will take and together with other issues types we can understand what will fit a single sprint. 

What do you think? 

[Nic Brough -Adaptavist-]

I'm sorry this has taken so long to answer!

There are now two different approaches in Jira.  Originally, we had time estimates, which work-logs were counted against, and you could use them in sub-tasks and roll them up to parent issues.

Then Scrum got added to Jira.  Scrum has nothing to say about what you estimate on, or how you accumulate it, but it does have a very clear principle about "done".

When you go into a sprint, you are telling your product owner that you are going to deliver a set of stories.   There's a lot of ways to estimate these, and you can, and should, use estimate to measure delivery.

But sub-tasks are irrelevant to Scrum delivery - you committed to doing (say) 7 items.  You broke them up into 3 subtasks each.  You got 20 of the 21 sub-tasks done, great, but as the product owner, you said 7 items, and only gave me 6.  I don't care if item 7 is 0, 1, or 2 sub-tasks complete, it's simply not done.

So, Jira does it the simple way, and works off the binary done-or-not.

If you are going to do Scrum with Jira, you do not put estimates on sub-tasks!

[Andrew Rose]

My product owner would definitely want to know how soon the missed story is likely to be delivered and knowing the relative size and time remaining on the outstanding tasks is an important part of that conversation. To give context we work on short sprints of one week so the hours involved is relevant when working with that cadence.

It is also an essential part of planning at the start of the sprint to ensure you have correctly sized the work involved on new stories and roll over stories. Cannot see an argument where it is not helpful in good clear communication with any stake holder.

[Nic Brough -Adaptavist-]

Nothing wrong with that.  You just have to do it separately from the Scrum estimate because it's nothing to do with that (unless you want to automate something to bind it in)

[Andrew Rose]

All I am asking for is that the time is presented at the end of the graph as there is no indication of scale. 50% complete on a 6 day task is not the same as 50% on a 6 minute one, having the scale allows immediate understanding of the data it represents.

[Mike]

Hey @maayan 
How did you accomplish such view in the backlog? I really would like to know how you managed to display the Original estimate of each sub-task and the summary of all original estimates below. 
Can you help me to achieve the same result?