Updating sprint capacity during sprint in Jira-Greenhopper

I made a mistake when entering my sprint plan in Jira/Greenhopper: it turns out we have a little bit more ca开发者_StackOverflow中文版pacity than planned.

This happened the second day of the sprint, but if I add the extra issues after the beginning of the sprint, the red 'guideline' starts from our original estimate.

Is there a way to avoid this?

I've encountered the same desire to 'adjust' the guideline in the sprint report a few minutes after starting a sprint.

I've solved it in the following manner:

• Go to the 'Plan' tab on your Agile board
• Set the start time of the sprint after the the timestamp of your adjustment
• Check the sprint report (it should be fixed)

As I understand the question the problem that you are facing is that the red guide line is drawn from the amount of work entered at the start of the sprint down to the end date for the sprint.

When you add more work to the sprint after the first day the guideline doesn't move. This can't be changed. See the thread here for discussion on that topic.

I think the logic here is that you should have all of your work defined and estimated at the start of the sprint and if the estimate increases after the first day then that should be because the tasks are more complex than first thought, not because you added more work.

I agree that it would be good if there was a new 'line of best fit' between your current remaining work and the end date to show the new level of velocity you would need to reach, but that is not supported.

I've added stories before to an iteration, and the burndown just ticks up with the additional, to show what else has to burn down. Greenhopper will represent the uptick an adjustment to the estimate, since it was added mid-iteration, but the remaining work is increased and then continues to burn down appropriately.

Abnormally terminate the sprint and restart it could be an option here. Since you already have the bulk of the items selected the sprint planning meeting for this could be in a very small time-box. Since you abnormally terminate you definitely can skip the sprint demo, you may want to have a short retrospective if you want to discuss how the problem/error happened, but I doubt it. You could be up and running with a new sprint in a few hours.

A late added task can be forced to be considered at the begin of the sprint using a workaround: log a minimum amount (1minute, e.g.) of work at the sprint first day.