2

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):

https://i.imgur.com/5CyMOrK.png

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).

Colorado Techie
  • 1,302
  • 1
  • 13
  • 21

1 Answers1

0

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.

jessehouwing
  • 106,458
  • 22
  • 256
  • 341
  • Thank you. I waited until the next sprint started (today, 3/21) and then started moving unfinished workitems out of the old sprint (the old sprint ended 3/18) and into the new sprint and unfortunately, the completed percentage on the old sprint keeps rising. Thus it seems that waiting until after the old sprint ends and the new sprint starts isn't working to change the burndown completed percentage. I'll keep trying, though. – Colorado Techie Mar 21 '22 at 17:27
  • I've recently encountered this and it seems devops solely cares about the iteration path for completed items. I can put items back into the past sprints to change the completed percentage. How can we account for unfinished work moving between sprints and accurately reflect that in our burndown charts? – Ben Aug 25 '23 at 17:27