1

I am facing an issue with the burndown chart in TFS. Fe. Sprint 1 - we have 9 work days. The sprint finishes and there are 6 tasks left so they have to be moved to the next sprint (sprint 2). We are doing the drag and drop of these tasks to the next sprint (sprint 2), but in this case we have a problem with the burndown chart for Sprint 1. This sprint 1 chart will see this sprint as a fully success, because all left over task were moved to the new sprint.

How to handle this problem so we have a good burndown chart for all sprints, even the provious one?

Eliza
  • 11
  • 1

4 Answers4

0

Can think of an alternate solution here.

If the issue is to have a consistent way to represent how much was committed during a sprint vs how much was completed, a better handle I'd advocate for a Sprint Burn-up Chart over a Sprint Burndown. This adds the detail on the amount of work that was committed and Modified over the sprint against the amount of work done.

Unfortunately, am unable to find a good link which helps creating one in TFS. But you can find the basics of a Sprint Burn-up chart and its pros over a Burndown chart here: https://www.sealights.io/software-development-metrics/burn-up-chart-exposing-scope-creep-and-revealing-your-real-progress/

And the one Image to sum up the Change shall be this:

Burnup vs BurnDown

Chandra Mouli
  • 1
  • 1
0

At the end of the sprint the burn down has served it's purpose. You have had your chance to adjust score and to apply focus within the team to best try to deliver what you had set out to achieve.

Now that the sprint is over and you are about to start a new sprint, why even care about the state of a previous burn down chart. There is nothing you can do about it now. It's all water under the bridge.

The only thing that truly matters is the new sprint backlog and the work the team is doing to try and achieve this new sprints objective. A new chart may help you with that.

If you truly care about the state of the burn down after the sprint is over, wait until the next day to move the tasks over to the new sprint, this will cause the history for the last day of the sprint to be stored correctly and the burn down will match what you desire.

If you do move the tasks out on the last day of the sprint, Azure DevOps/TFS will track this as a deliberate scope change in the sprint and will (correctly) set the remaining work to 0.

jessehouwing
  • 106,458
  • 22
  • 256
  • 341
-1

As far as I can see, it depends on the date when you finish the sprint and plan the next sprint:

  • if the date is the last day of the current sprint, the burndown of the current sprint will show 0 remaining work, which is not what you want
  • if the date is the first day of the next sprint, the burndown of the current sprint will show the actual remaining work at the end of the sprint

If the above is correct, the solution would be to end the sprint the day AFTER the last day of the sprint.

Christophe Herreman
  • 15,895
  • 9
  • 58
  • 86
-1

Usually this happens when the external input is done in a running sprint which is not properly estimated eventually causing the unfinished tasks at sprint end. One suggestion is that you can create an 'Impediment Backlog' instead of moving unfinished tasks to the next sprint. 'Impediment Backlog' will work as a bridge directly between your running and upcoming sprints and indirectly to the actual backlog itself. You can easily track your unfinished tasks through this. For more details pls read topic below:

http://scrummethodology.com/scrum-impediments/

https://www.projectmanagement.com/blog-post/54093/How-an-impediment-backlog-can-help-us-to-get-our-issues-under-control

Shakir Mushtaq
  • 1
  • 4