We've started using Azure DevOps and sprints and for one of our sprints (sprint 4, 2/21-3/4) we didn't finish all of our workitems, so we moved the unfinished ones to the next sprint on the last day of the sprint (3/4).
But now our burndown chart for that sprint shows 100% (even though we only finished 80% of the workitems):
What should we be doing in order to preserver the real Completed percentage? (e.g., if we only finish 80% of the workitems, I'd like the "Completed" percentage to always show 80%).
Some Ideas:
- Waiting until after the last day of the current sprint (3/18/2022) and move the incomplete work items to the next sprint. I tried this today (3/19), but the completed percentage went up when I did that. I will try again after our next sprint starts (3/21).
- Splitting unfinished workitems and leaving the unfinished one open forever (I don't like this idea).
- Stop using the "Count of Workitems" for our burndown and instead use tasks (I'm not sure if this will work though, because we'd likely still have unfinished tasks at the end of the sprint that we want to move to the next one).
In the end, I can't find any definitive way to solve my issue in the Azure DevOps documentation and I'd love to know the "right" way to end a sprint to preserve the real percentage complete when we don't finish all the work. (I'm hoping waiting to move workitems after the next sprint starts solves the issue).
The burndown will reflect the remaining work in a sprint. If you add work to a sprint, the burndown goes up. If you move work out of a sprint, the burndown will go down. So when you remove all unfinished work out of the sprint, the burndown will track to 0. That's expected.
The burndown is also a tool to track progress towards your spint goal and only really serves any value during the spint. Once the sprint is over, you can't change anything anyway. And how much you promised vs how much you actually delivered becomes a moot point.
Waiting until you are past the end date if your sprint before moving the items over is likely going to work. Just keep in mind that the end date ends at 0:00 in the server/organizations configured master timezones, likely a couple of hours part the end of your working day.