Sprint Burndown trend does not approach To Zero
Hello All,
We are using RTC 4.0 and our sprint burndown report for a particular iteration has not reached the zero point although all the workitems have been closed.
This is how the Image looks like.
The Iteration is from 28/08/2013- 17/09/2013. Total items in sprint is 46 and all of them are in closed state.
The ETL data jobs have been run and yet it shows the same.
What could be the reason ? Does the burndown not consider workitems which are modified or resolved after 17/09/2013 ?
We are using RTC 4.0 and our sprint burndown report for a particular iteration has not reached the zero point although all the workitems have been closed.
This is how the Image looks like.
The Iteration is from 28/08/2013- 17/09/2013. Total items in sprint is 46 and all of them are in closed state.
The ETL data jobs have been run and yet it shows the same.
What could be the reason ? Does the burndown not consider workitems which are modified or resolved after 17/09/2013 ?
Accepted answer
I think this is because RTC uses the estimate, correction and the time spent/time remaining on execution work items (tasks, defects etc.). Just by closing a work item, the data is not necessarily correct.
I believe If you run in time spent mode, time spent must be set equal to the estimation/correction. In time remaining mode the estimate/correction have to have the time spent and time remaining must be 0.
I have read about some customers that created automation (follow up action or calculated value providers) that made sure the data is correct when closing work items.
I believe If you run in time spent mode, time spent must be set equal to the estimation/correction. In time remaining mode the estimate/correction have to have the time spent and time remaining must be 0.
I have read about some customers that created automation (follow up action or calculated value providers) that made sure the data is correct when closing work items.