RTE in a Burndown Chart is not zero at Sprint End

[antonsarov]

We have a workflow where the Remainig Estimate is automatically set to 0 minutes upon Sub-task completion.

The problem we are facing is that the Remaining Time Estimate on the Burndown Chart is not at 0 at the end of the Sprint even though all stories were completed

If you look at the picture, the RTE stays at around 1w 3d - this is exactly the SUM over all Sub-tasks of the difference between Original Estimate and Work Logged.

Can somebody explain this behavior and offer an advice on how to improve?

[Earl McCutcheon]

Hello,

I would recommend reading through the following article as it gives a really good break down on the behavior of the burndown report for scenarios that lead to the behavior you are seeing:

• Understanding the Jira Burn-down Chart

You will want to review the data for the issue in the report primarily focusing on the worklog and the Burn Up events as described in the article above.

There is also the possibility that you are running into the following BUG where the burn up can occur twice when moving sub-tasks between Parent issue in an active sprint:

- https://jira.atlassian.com/browse/JSWSERVER-15613

Regards,
Earl

[antonsarov]

Hi Earl,

the article mentions that it could happen for the burn-down to be greater than the burn-up when teams overestimate the time needed. For some stories this was the case but this still does not explain why at the end we have almost 2 weeks of unspent burn-down.

Somehow I have the feeling that the RTE in the Burndown is not properly reflected. Look at this part of the report below the Burndown Chart:

19/Jun/18 4:21 PM	ABC-1 / ABC-2	Work logged	20m logged, Remaining Time Estimate changed from 2h to 1h 40m	20m		20m		20m	3w 2d 5h 40m
19/Jun/18 4:22 PM	ABC-1 / ABC-2	Issue state change	Issue completed	0		20m	0		3w 2d 5h 40m

Story ABC-1 has a Sub-task ABC-2 which had Original Estimation of 2h.

Row 1: This task was completed in just 20 minutes, which were logged via the Log Work function. The Remaining Time Estimate of the task was properly decreased to 1h 40m and the global Remaining Time Estimate was properly decreased to 3w 2d 5h 40m (we started with 3w 2d 6h)

Row 2: The Sub-task was moved from In Progress to Done and now our workflow function kicks in and sets the Remaining Time Estimate of the task to 0m. Note, however, that the global Remaining Time Estimate stays at 3w 2d 5h 40m.

Over the course of the sprint the global RTE is being reduced only by the logged work and not by the removal of the RTE of the tasks. And after many weeks we end up with a global RTE of 1w 3d.

So the whole thing is contra-intuitive. You have completed ALL your stories in the Sprint but the Burndown Chart says that it estimates that you still have to work 1w 3d. Can you please elaborate on that?

[Earl McCutcheon]

Hello,

You noted that you have a workflow post function set to put the remaining time estimate to 0, I think there might be an issue in the Post function you are using.  

I did a few test using the process outlined in the following KB using the jira native Post Function Update issue field  setting the field value to NULL for remaining estimate:

• Set Remaining Estimate to 0 on post function

But in all the scenarios I threw at the sprint the burndown always set to 0 and reflected correctly in the chart.  Are you possibly using an post function from an add-on? and what is the defined order of the post functions you have set up on the transition? What Workflow Post Function do you currently have set up?

Regards,
Earl

[antonsarov]

Hi Earl,

the post functions are defined like this:

Except Number 6, all the other post functions are the "standard ones" that come with the Software Simplified Workflow for Project...

We are not using any add-ons, we just created this post function manually.

Is there a difference if you leave the field "Remainig Estimate" blank or set it to 0 when you create the function? With the empty field the Time Tracking of an item looks a bit strange, having Remaining as "Not Specified":

Thanks,

Anton

[Earl McCutcheon]

Hey Anton,

Thanks for the screenshots, and it looks like a post function order conflict.

You will want to move the #6 post function that clears the Remaining Estimate Field so that is is above #4 which generates the change history item. 

The Report is pulling the value from the change history which has the value present at that point and then indexed with the value present but removed after these actions occur.

Also in post function logic you always want the last two Post function events to be in the order of the Reindex event then the Fire Issue Event function, this can cause odd rendering issue on the issue view and data collisions if a field is modified after the index is updated as in the current odder the index has the valued stored in the field but the data was cleared in the backend by the post function events.

Set up the post functions like this and you should be good:

Regards,
Earl

[antonsarov]

Hi Earl,

thanks for the suggestion! I have corrected the workflow as you proposed and will observe the behavior. If everything goes smooth, I'll mark the answer as accepted.

I realize that this is an error on our side but given the fact that we followed the guide mentioned in the KB, I still find that this information should be there in the first place. I expect that other people may stumble upon this as well.

Best regards

Anton