Incorrect estimation in user stories with sub tasks

[Svein Seldal]

We're trying to setup Jira Agile to our workflow. We do time based estimation, not story points etc. We usually add user stories and let the technical team break it down into sub tasks in which the tasks are given time estimations. The sum of the subtasks makes out the total estimation for the user story.

How can we get the estimate field in the sprint/backlog list (the circled numer to the right) to show this sum? As it is today the sprint shows the task sum in "Remaining" field, but not inside the "Estimate" circle, so it does not show on each story.

However, if I add an estimate to the user story, I get the number in the circle. However the remaining field in the user story issue and the sprint remaining sum shows the sum of the sub tasks AND the user story. This is not correct either.

The picture below shows that TEST-25 has two sub-tasks TEST-26 and TEST-27. Both with 1d estimate. Hence the estimate for the user story would be 2d. However the 2d does not show in the sprint list circle, because TEST-25 has not been estimated.

Adding an estimate 2d to the user story does not make things right either it seems. It shows correctly in the circle in the sprint list. But it reports 4d remaining work, which is incorrect.

[Ed Henderson]

I am really sick of this issue "being an issue". I can't fathom why Atlassian does not see how this is a problem?? 

This is just a major major annoyance and it really needs to be resolved. 

[Antero Karttunen]

Hello, any update on this ???

[Nader Rahimizad]

any update on this issue since this thread seems to be aged a bit... ?!

[George Purtell]

Any update here? Hard to believe this issue has not been fixed yet. Our team is estimating by time, still running into the same problems listed above.

[AnshulRepository]

Challenges & Limitation in JIRA:

If we estimate a user story in (Hours) and plan to execute in our Sprint. Obviously, there are multiple peoples working on the same user story according to the set definition of done. Now for distributing the user story in multiple resources either in terms of Tasks or Sub-Tasks.

Task Case:

If we divide in terms of Tasks and giving the original estimated hours in each of the tasks, then the original estimated hours which is given in the task is not reflected in the user story and it adds the total estimation. Also, Tasks and User Story is work on the same level in JIRA. Hence we need to relate each of the tasks with the user story which is also an overhead and not recommended.

Calculation now: Original Estimated Hours (User Story) + Original Estimated Hours (Tasks).

This gives us the wrong result.

Sub-Task Case:

If we divide in terms of Sub-Tasks and giving the original estimated hours in each of the sub tasks, then its total subtask original estimates showed on the User Story but the problem is it is not showing the Original Estimation of the User Story in the Sprint Report and also when to see the Sprint Backlog it is not showing the Original Estimated hours only shows the remaining hours in the sprint.

Note: In both of the above cases we are unable to satisfy the condition of the Estimation process in JIRA.

Mitigation Plan in JIRA:

1-      Decide the Definition of Done of the user story. (Decision is taken from the dev team what exactly they need to fulfill the user story in sprint). As the team mature more with time they will pick more items from the Task List in the DOD for better driven off the user story and completion.

Sample List of Tasks	Sample List of DOD
User Story Documentation	User Story Documentation
UX/Design	UX/Design
Test Case Development	Test Case Development
Coding	Coding
Unit Testing	Unit Testing
Code Review	Code Merge in Dev Server
Regression Test	Regression Test
Integration Test	Functional Testing
Functional Test
Stress Test
Performance Test
Code Merge in Dev Server
Code Merge in Test Server
Code Merge in Prod Server
Smoke Testing
Code Freeze
Bug Fixing
Configuration

Benefits:

1-      Quality

2-      More Accurate Estimates.

3-      Team commitment and Focused Work for the User Story

4-      Continuous Delivery in the same format which is easy for the team.

5-      If anything pending in it then it is not passed at the end of sprint for doneness of the user story. (No compromise with the quality)

2-      Estimate the User Story in terms of the Story Point Calculation.

For measuring the Story Points calculation, we need to define the range of the Story Points. We take the Fibonacci Series (1,2 3,5, 8 …) for defining the Story Points numbers.

Set the range of the User Story Estimation. The range is set as per our own convenience:

Example:

Story Points	Hours Range (Example)
1 story points	0-4 hrs.
2 story points	5 – 8 hrs.
3 story points	9-12 hrs.
5 story points	13- 16 hrs.
8 story points	17-20 hrs. (More than 8 story points is not recommended, divide the user story to take estimates within the range. )

3-      Distribute the user story in terms of Subtasks to the team members and gives the original estimation hours, remaining hours, time spent in it.

4-      Measure the Sprint with the Story Points.

5-      Velocity Chart comes in terms of the Story Points which gives the exact scenario of the team velocity.

6-      Burndown Chart shows the remaining effort in terms of the Story Points against the sprint duration.

7-      Burnup chart shows the scope variation and all the work progress in terms of Story Points.

8-      If the user story is not done means some of the subtasks is not completed. User Story is not accepted as done. It will move to the backlog and the entire story points are not calculated in the velocity measurement. (This is rule either done or not done).

9-      It’s very easy for moving the user story associated with all subtask from one sprint to another sprint or in the Backlog.

[Yuriy Grinberg]

after 2 years this is still broken

whatever "process" suggestions may be, the basic structure of tasks with subtasks dictates that subtask estimations be summed up.

In fact the "Backlog" screen shows the sum when the issue is selected, why is it still shown as "Unestimated", why is it not reflected in the sprint ?

JIRA version ( v6.3.13#6344-sha1:62d2b41)

[Marius George]

No solution yet.

[Andy Loughran]

Same here - would be good to get stories to use 'time remaining' rather than 'original estimate' in charts and plan board.

[Dave Collins]

@Jeff Sieffert: I agree. Our hiearchy is Epic > Story > SubTask. We give story points to the ST's, but the parent (story) does not inherit them. This is very 'off' for doing burn downs accurately.

Surely there is a solution?

[Dave Collins]

I was sent this response, and I will give it a shot. Hopefully resolves the issue I'm encountering. The problem is, the burndown charts are built around story points. I feel this is still a major flaw in the Jira tool. The use of story points is poorly implemented.

Put your total estimate as the original estimate of the Story (parent task) and leave remaining estimate blank.

In each subtask, put a remaining estimate, but no original estimate.

Its a little weird, but if you do this, everything starts to make sense.

[Nader Rahimizad]

any update on this issue since this thread seems to be aged a bit... ?!

[Jeff Sieffert]

If Jira allows project estimation based on "Original Time Estimate" and the time tracking to track time against issues using JIRA's Remaining Estimate and Time Spent fields, how am I supposed to plan a sprint that is based on remaining time if it is not calculated using subtasks?

Estimating at the subtask level adds granularity and makes it easier to estimate smaller tasks. I fail to see the argument of subtasks making things more difficult. I agree that tasking and subtasking a story costs extra time but it also adds a much more realistic idea of what's involved in the development.

[Zachary Drummond]

@Daryl: This is answering a question about broken functionality with a process document.

Sure, yes, Story Points are awesome....

That said, how does it address the fact that JIRA Agile refuses to total sub-tasks in the Sprint board?

[John Burns]

Put your total estimate as the original estimate of the Story (parent task) and leave remaining estimate blank.

In each subtask, put a remaining estimate, but no original estimate.

Its a little weird, but if you do this, everything starts to make sense.

[Dave Collins]

However, this does not work for the burn down. It will still reflect the Story Points.

[Földes László]

As of now, setting the Remaining estimate automatically sets the Original estimate.

[darylchuah]

Hi Svein

This is actually an expected behaviour from JIRA Agile itself. I believe the following blog post will give you a very comprehensive and detail explaination on this

http://blogs.atlassian.com/2012/09/agile-qa-greenhopper-time-estimates-with-sub-tasks/

However it will be quite a lengthy article, please do spend some extra time to read through it :)

[Svein Seldal]

I will read the blog, but until that I believe there is an unexpected incosistency in agile when using time based estimation. It sums up remaining time and estimated time which I find very confusing.

If I change back the scrum to story point estimation I get the below image. Here you can see that the user story has an estimation of 2 and it shows two in the sprint "circle". The remaining sum is set to 2d in both the sprint list and the issue. Which is both correct and expected.

[Svein Seldal]

After reading the blog, let us simply say we use story point and let me rephrase my question:

Can we add story points to sub tasks and make Agile sum them to present the number in the parent user story? Will Atlassian ever implement this?

The I know the blog argues for not breaking down into sub-tasks when doing estimation because is creates inprecision of the velocity.

However, that is how our story points are estimated today. Right or wrong. The product owner comes with a story "I want new feature X". It not until the story has been broken down into smaller chunks (sub tasks) that the story really can be estimated into story points. The sum of all these story points make out the user story's story point.

So perhaps the solution is to create more fine grained user stories and move the original user story to an epic, but that creates other problems: Then I think we would need a level above epic replacing the original epic.

Example: Given epic "Want new car model" from mgmt. Then this is by product owner broken into user story "Make new engine" and "Make new body". This is clearly too broad to be estimated, so it the first is broken into smaller "sub-user" stories "Make new engine block", "Make new alternator" by the technical teams which can be estimated. Thus three levels: epic -> user story -> sub-user stories. This is one more layer than jira supports. So I adopted using epic -> user story -> sub-task. But apparently not intended to be used this way.

[Deleted user]

Based on this discussion, i decided to start my sprint not estimating the user stories.

not estimating the user stories, but limiting estimations to subtasks, seems to give the correct burndown charts.

using estimations in the user stories and subtasks results in wrong reports since the estimations of the user stories and subtasks are additional; the estimations of the user stories are not a sum of the subtasks.

by the looks of it, the only thing missing is the time indications on the planboard when you don't use the estimation value of the user stories?