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?
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?
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!
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.