-
Bug
-
Resolution: Not a bug
-
Low (View bug fix roadmap)
-
None
-
6.1.5
-
Standard Jira/Greenhopper distro on RHEL Linux 6.2, MS SQL Server 2008 database.
-
6.01
-
When creating a Task and then creating Sub-Tasks beneath it, the Remaining value is properly populated with the total number of hours estimated for the Sub-Tasks. However, the Estmate field is left blank (shoudln't it contain the sum of the Estimate values for the Sub-Tasks?). This makes Sprint Planning a little difficult since the Remaining and Estimate values on the Sprint Plan don't match. It also makes tracking a little more dificult because it is harder to compare the initial Estimate with the Remaining value during Sprint execution.
- is duplicated by
-
-
- Closed
-
- is related to
-
JSWSERVER-13138 Sum estimates from sub-tasks in user stories
- Gathering Interest
-
- Future Consideration
[JSWSERVER-8173] Greenhopper not populating Estimate field with sum total of Estimates from Sub-Tasks
Hi marionr,
This is intended behavior. There is currently no way to roll these estimates up to the parent. For the rationale behind this decision, please read this post on answers.atlassian.com:
https://answers.atlassian.com/questions/84349/rapid-board-time-estimates-with-sub-tasks?page=1#84605
Hope this helps.
Hi Peter,
I understand the rationale and have used Jira this way before (both for story points and person-hours). The behavior I have issue with is that when you get to the “final” estimate before allocating a story to a sprint, the best way to gain that better accuracy is to break the original story (with its PBI) into sub-tasks. The current behavior of Jira adds the sum of the estimates for the subtasks to the PBI as they are created and places that amount into the field that contains the “Remaining” effort.. Based on what I read in the article, this violates the stated preference a separation for isolating the PBI from the tracking estimate and causes the tracking estimate to be artificially inflated because you are counting the same work twice: once for the PBI and again for the final, pre-sprint estimate that is used for commitment.
If the Estimate and Remaining values were truly independent, I think the statements in the article would hold a lot more water in terms of providing benefits by allow us to compare actual velocity to our PBIs.
Ron