Roll up sub tasks estimates to sprint level

Question

This has been asked before, but I do not quite get the answer. I have a parent task with estimate as 0 and two sub tasks with 2d estimate each. If I put that parent task in the sprint, the sprint shows only 0 as the work in progress/done/remaining etc.

I understand the point about splitting estimation from tracking and using story points ... but still if I prefer estimation in hours ... can I have the sub task time estimates show up at sprint level? I did configure the board to use the original estimate as the estimation method.

Max Cascone · Answer

Daryl, If you read to the end of that article, the last paragraph states:

All of that said one of the key precepts of Agile is finding the way that works for you. So GreenHopper does support the alternatives described above including the use of remaining estimates for sprint commitment, hours for estimation and hour estimates on sub-tasks.

So it's questionable to be relying on that post as an excuse for why Atlassian won't support a different way of planning/tracking work.

Ubisoft1 · Answer

Hello, I have made a workaround I did a little something its not perfect at all should any of you do better just put it here. - It add a button left of PLAN mode - It work only for certain user since it can create a load on the isntance (get the issues data in rest) It add the sum of subtask instead of story point/time estimate when you click on it. Also add a custom field (we have another kind of priority system) Add this code into the Announcement banner So here is it I made it quick but ajust it to your need Martin Poirier Ubisoft

Amit Agrawal5 · Answer

Daryl, thank you for your answer, but I read that blog. Even my question acknowledges that - that I understand the point about splitting estimates from tracking. The question was, more of, it should NOT have been hard to implement, and if someone wants to do that the tool could have provided an option to do that.

MS Project 2010 launched a new feature - manual scheduling. Prior to that many teams would not use MS Project because MS Project would automatically adjust the schedule if e.g. one changes the duration. That made scheduling very tough (or easy depending on how you see it). They could have taken the line ' learn project management and then start using MS Project .... which I think they did take for a long time before giving up in 2010.

And I do not agree to the whole point about the story points being less accurate and hours more accurate. A team might as well apply the 'same degree of inaccuracy' to hours than some artificial story points.