How to handle Stories that don't get completed

[Phil]

I wanted some general advice on an issue we have been having.  I create a user story with a set of tasks underneath it.  I schedule the story for Iteration 10.  Due to unforseen circumstances, not all of the tasks get completed in this iteration.  Do I now move the entire Story to Iteration 11?  What is considered best practice here?

[Ivan]

Hi Phil,

There are two thing that you could do in your situation depending on the case.

The best way is to split the story into two stories. You can mark the old story as done and create a new story for the new iteration. You will have to move the undone task to the new story.

Anyway in some cases it is not possible to split the story, so you should move the whole story to the new iteration. Note that task marked as Done or Deleted will not move to the new iteration.

It's up to you which method you should use.

If you have any other questions feel free to ask us at any time.

Regards,
Ivan
Telerik

 

[Phil]

So this partially works.  I am in the middle of doing some of this planning.  I have a user story that had 19 hours estimated on it.  There are 4 tasks on the story, totaling 19 hours estimate total, so we updated the story with an estimate of 19.  We have completed all but 3 hours of work, but I need to move those 3 hours to the next iteration.  I go into Iteration planning and move the user story.  On the next iteration, my usage went from 320 hours to 339.  It increased by 19 hours, not the 3 remaining.  

So my burndown chart is now going to start at 339 when, in reality, I only have 323 total hours of work.

How can I solve this?

[Zornitsa]

Hello Phil,

From your email it looks like you are using a burndown by Estimate and in this case the tasks estimates won't be used in the burndown calculation. To use tha task estimated for the burndown calculation you will need to change the burndown mode to Task estimate. You can change the default burndown mode from the Reporting Settings tab in the project settings and you can change the burndown mode for a single report from the Burndown mode dropdown in the reports settings or in the iteration status page. Here is more information on the difference between the burndown types: http://docs.telerik.com/teampulse/project-administrator-guide/reporting-settings

So in order to move the story to the new iteration and keep only the remaning 3 hours in the calculation using the burndown by Task Estimate, you need to have the completed 16 hours within other tasks all set to done (which will mark the tasks as completed) and the 3 hours into task(s) in status different from Done or Deleted. Thus, the tasks with status Done (with total estimate of 16 hours) will remain in the past iteration, and the task with estimate of 3 hours will be moved into the new iteration. The estimation set for the story won't be calculated in the burndown report.
You can find a more detiled information on how to use the PERT task estimate here.

Please review the settings of your burndown report and let us know if your setup is a different one so we can suggest a different solution.

Regards,
Zornitsa
Telerik

 

[Phil]

My setting are already set to task work remaining for this project.  I was already aware of the options so I had changed this a while back.  The only thing that might be throwing it off is that the tasks weren't "done", just the time remaining had been reduced.  I still am not sure why the "Iteration Planning" view seems to be using estimate instead of work remaining, but it is.

Also, on the burn down charts, and this is a huge problem, my forecast line is WAY off.  How is this calculated.  Based on our current burn rate, we are behind schedule, but the chart predicts us being done several days early.  This is causing extreme frustration when trying to report project status.  I have attached my report file.

[Zornitsa]

Hi Phil,

I have noticed that your burndown calculation is a forecast one - this new calculation mechanism was introduced as a replacement of the previously used trend mechanism to improve the handling of increasing the remaining work by adding new work items. The difference between the trend and the forecast mechanism if that the forecast mechanism doesn't predict the addition of new work based on the work added before and calculates the forecast based on the work remaining at the moment and the current trend for completing tasks. 
As breaking the stories into tasks, usually done during the first few days of the iteration, often leads to adding new work and setting more precise estimations, the about even or sometimes even upwards slope of the actual line in the burndown is normal and the forecast will be downwards because the prediction doesn't follow the upwards slope from the new work added. 

The Iteration planning screen used by default estimates for the capacity calculations presented on the iteration cards. However, the burndown mode used in the Iteration status screen and in the reports is the default mode selected in the project settings. 

Do not hesitate to get back to us if you need any further assistance.

Regards,
Zornitsa
Telerik

 

[Phil]

I understand what you are saying, but where is it getting the "current trend" for the forecast.  The slope of this line is far faster than we are actually able to complete work.  When I go to publish this report, I will have management asking why we don't add more to the iteration since we are going to be done so early, when we will truly be late.

[Zornitsa]

Hello Phil,

Did you have a chance to check the burndown again after a couple of days?

The forecast algorithm is based on the velocity in the Iteration up to the moment and the speed could be faster or slower in the beginning of the iteration if the velocity for the first day has been higher/lower than the average for the whole period. Basically, the forecast is getting more precise the further in the iteration we are because the velocity is calculated based on more data points and the forecast in the beginning of the iteration may not always be reliable because of the limited data. However, this highly depends on how even the workload is spread and the correct logging of the data. Also, please keep it in mind that the estimates may differ from the actual time spent on the separate tasks and these differences may also speed up or slow down the burndown.

Please review the burndown again and let us know if you have any concerns on the algorithm used. 

Regards,
Zornitsa
Telerik

 

[Phil]

It is "better", but not "good".  It is still predicting our work to be done faster than our actual burn down rate.  I am well aware of the differences between the estimate and the actual work.  Based on PMI training and the way I was taught to calculate burn rate, this slope of the forecast is still far too quick.  We have not had much additional work this iteration.  The forecast line should just be an extrapolated line based on the average slope of the work remaining over this iteration, and yet it is clearly not.  I will continue to monitor over the next iteration as well and see what happens.  

I would prefer a way to have the forecast simply be the average slope over the iteration as projected from the current day onwards in the future, if this is possible.

[Zornitsa]

Hi Phil,

Thank you very much for your detailed feedback on the burn rate calculation. It is a valuable input for us.
We will need to discuss this matter internally and we will get back to you next week. 

If you have any other questions or ideas, feel free to write us at anytime.

Best regards,
Zornitsa
Telerik