Sprint Burndown of Sub-Task Hours

Brent Walker_bd51d7

I have always used Story BurnUp to indicate the level of Done-ness for my MVP.  Where I estimate my MVP ("Y" axis) in points at beginning of planning.  Each iteration ("X" axis) some number of points are completed and then a burn up of points on the graph towards plan.  I have also used cumulative flow with a cut line for MVP.

What I want to see is an Iteration BurnDown of hours left for the sum of sub-task(s) remaining hours to complete a story.  Say we have 3 stories with the following points: 3, 1, and 5 for a velocity of 9 points per iteration.  The hours to complete the stories are as follows:

• 3pt story = sub-tasks added totaling 3 effective workdays (6.5*3) for a total of 19.5 hours
• 1pt story = sub-tasks added totaling 1 effective workday of 6.5 hours
• 5pt story = sub-tasks added totaling 6 effective workdays of 32.5 hours
• Total hours is 58.5 hours

I would start my burndown at 60 hours (or some number above 58.5) and place a point at the start of iteration at 58.5 ("Y" axis).  Then at the end of day 1 ("X" axis), all team members update their tasks with new time remaining and sum up all remaining hours. Second dot would be something less than 58.5 or may be more as the result of learning new things that made the estimate larger than original estimate.  This would continue until end of iteration and graph updated as such.

This is purely used to help you understand if your iteration commitment will be met early within the iteration.  the trend can then be extrapolated to show you if you are delivering late/early or may need to drop scope within the iteration in order to get highest story completed.

Anyone have any suggestions for accomplishing this with cloud instance of JIRA.  I cannot seem to make it happen.  Of course maybe it is a permission issue.  I currently have project admin rights as well as scrum master.

Thomas Deiler_db00h3

Dear @Brent Walker ,

welcome to the community.

First of alI, there is no built-in report, that burns down hours, because sub-tasks are not taken into account. Eventually the work estimate is aggregated in its parrent issue.

On the other hand, I do not see any benefit in such kind of burndowns. Story points are a relative currency. When the team adds a duration estimate on subtask, they probably to this for better calculation, if the amount of stories is managable within one sprint.

But as soon as the sprint starts, forget about the time estimates. From now on it only counts that the team achieves its mission - regardless how.

They promised to finish the commited stories. Trust them.

When the teammates work focused - so starting with the highest ranked story and finish it before the next, you will see a well-formed story burn down - the trend should be clear.

If not, the reason could be, that either the stories are too huge or the teammates have lost focus (starting everything at once) or both.

So long

Thomas