I understand that the biggest worry in a sprint is scope-creep so you wouldn't normally want to do this. However, I've occasionally started a sprint and then realized that there were a few stories we forgot to estimate story points for. Now I can't add that without completely screwing up the burn-down chart.
I understand you're trying to encourage best practice here, but now I can't actually follow those practices because of the restrictions in place.
Am I missing something?
The burn-down chart is just a report. It just reflects what you do. So indeed, if you change estimates on issues already in your sprint, this is reflected in the chart as an increase in story points. Simply because that's what it is.
I would not call this restrictive. There is nothing that blocks you to add or change estimates already in the sprint. There is also nothing that stops you to remove issues from an active sprint either.
The fix here would be to avoid that you start a sprint without unestimated items in them. So include a check of all planned items in your planning ceremonies before you actually start the sprint.
Good morning Members, Not sure if you are aware. Please read the following: https://www.icloud.com/keynote/0RyJ4VEdNUpjDpGfMhfZx9fEg#Confluence_Security_Advisor More details: https://co...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs