6

It appears that the TFS 2012 burndown works a bit differently than I expect.

Suppose my current iteration is at 100 hours remaining out of 200 total original estimate, and my three team members each create a task today, estimate each at 6 hours, and complete these tasks. Thus, we discovered and completed 18 hours of work that we didn't realize were there. I would expect the entire burndown to "shift up", have it recalculate based on 218 hours total, and we would now be at 100. Thus we would show a good burn for today: we burned down 18 hours, going from 118 to 100, remaining. The goal burndown line would get a bit steeper, and we would reevaluate if it is realistic given the newly discovered work.

However, it seems that TFS's burndown chart ignores the "original estimate" in some (all?) cases and would show no progress today; those 18 hours are not reflected anywhere in the burndown.

This doesn't quite make sense to me--the upshot is, if I create a task today and finish it today, no hours are burned; but, if I create a task today, work on it today, and finish it tomorrow, then some but not all of its hours burn. Really?

How best to deal with this situation? Do we need to change the way we think of this?

Improve this question

3 Answers 3

Reset to default
6

What you're seeing is how TFS currently works. I've logged this with the Product Team a couple of times, and I've heard a couple of ways it might be solved in the future, but for now your tasks found and solved on the same day are not reflected.

The funny thing is that the burndown will still be correct. Any hours found and resolved on the same day have a net result of 0 hours, so the burndown should remain in place. So you can trust the prediction (which is the most important piece of the burndown), but you cannot see exactly how much work was done each day (which scrum cares a lot less about).

There are a number of UserVoice tickets on this and a there might be bugs files on connect.

So, how to deal...

  • If you want the graph to be accurate, use the Report Server version of the burndown, I believe that that graph is correct.

  • Get the data from the warehouse using Excel Powerpivot and then you're completely in control over the algorithm used. (steal the Excel file from a MSF for Agile project's SharePoint portal)

  • Or draw your own burndown.

  • Do nothing and believe the trend.

Improve this answer
7
  • Thanks, that's very helpful. I agree the last day of the burndown will be correct, but the burndown on individual days is wrong, as it will show no work completed for such created and worked-on tasks.
    – Patrick Szalapski
    Commented Jan 22, 2014 at 5:26
  • Do you have any info on how to use the report server version of the burndown?
    – Patrick Szalapski
    Commented Jan 22, 2014 at 5:27
  • I would not put much value in the accuracy of the burndown. As a team we know what happened, others can ask us but the burndown should not be used for status reporting anyways, it's mostly a planning tool!
    – jessehouwing
    Commented Jan 22, 2014 at 8:35
  • Added links to Report server and Excel versions of the report. This requires that your TFS server is configured with Reporting enabled and/or Sharepoint integration.
    – jessehouwing
    Commented Jan 22, 2014 at 8:36
  • Unfortunately, looks like my team project doesn't have that enabled. Anyway, if the burndown is too inaccurate, there is no point to having it. If the instant-in-time comparison based on remaining work vs. capacity is the only relevant data, there's no need for a chart at all. Thanks for the info.
    – Patrick Szalapski
    Commented Jan 22, 2014 at 17:02
1

I think you are misunderstanding the purpose of the burndown chart. The burndown is there to show you how much work is remaining in a sprint at any point in time, not to record how much work you've done.

If you had 100 hours to do and you add 18 hours worth of tasks and burn down those 18 then the net effect on the work remaining is zero, hence the burndown chart will show zero progress.

I know it seems harsh to see no credit for the work but the fact is if you had 100 hours to do at the start of the day and those 100 hours still remain at the end then its right that the burndown reflects that.

Improve this answer
2
  • 1
    I disagree. If all I care about is remaining vs. capacity, why have a burndown at all--you just need two numbers to compare? The burndown shows recent history and trends. Suppose we have tasks that total 100 hours estimated at the start, and then discover 200 more hours of tasks later. Those 200 hours of work were always there; they just weren't discovered until later. I want my overall burndown to start at 300 hours, not 100--otherwise, the daily progress shown in the burndown is meaningless. Unplanned tasks are just as important as planned tasks.
    – Patrick Szalapski
    Commented Jan 24, 2014 at 17:08
  • Also, TFS does show these tasks in the burndown, it just fails to capture hours burned the same day the task is created.
    – Patrick Szalapski
    Commented Jan 24, 2014 at 17:14
1

Patrick, let me tell you very briefly how Jira manages this. Why? Because I believe it is the right way to handle it :)

In Jira you start the sprint explicitly. Once it is started, all changes to the sprint in regards to content leads to a changed sprint scope, either increased or decreased.

In your case - starting off with 200 hours and then adding 18 hours will never give you an "updated" start point of the burn down (e.g. 200 hours + 18 hours) because these are considered as a change to sprint scope.

What you will see is that the burn down get a spike equal to 18 hours on that day and, if burned down the same day, you will also burn down those same hours (see below around feb 12).

enter image description here

In theory (and our practice), if you start off with 100 hours because that is your capacity, and you suddenly find 50 more, you cannot just add them into the sprint. Because you do not have the capacity (unless you initiate lots of OT). If those newly found 50 hours must be done in the sprint you should remove another set of 50 hours because those hours are not what your team initially committed to (they commit to 100 hours, not 150).

I would say that the TFS burndown is wrong. But because it doesn't show the spike as Jira does, not because it doesn't increase/update the additional work added during the sprint.

Improve this answer
11
  • I agree that having the spike is better than nothing, but I would say the overall idea is naive. You are going to have dozens if not hundreds of hours of work discovered throughout the sprint. The waterfall attitude is that we plan everything ahead of time, but the agile attitude says that we react to changing circumstances (i.e. discovered work) by changing along with it.
    – Patrick Szalapski
    Commented May 14, 2014 at 18:38
  • "if you start off with 100 hours because that is your capacity, and you suddenly find 50 more, you cannot just add them into the sprint." Sure you can. The most common scenario is that I have 150 hours capacity, and 100 hours of tasks, and later in the sprint, 0-50 or more hours of new tasks get added. I've never had software work where all the tasks are predictable--there are always additional tasks that weren't understood before the work began.
    – Patrick Szalapski
    Commented May 14, 2014 at 18:40
  • Maybe we are talking about different things Patrick. I assume that when you use the burndown you work agile. And with agile the team commit to the work they believe they will be able to complete within the next sprint. That means that you plan "just enough" to believe that you can commit to the contents of the next sprint. Yes - some tasks will take more time, some less. But the entire concept with the burndown is to show the burndown of the committed content. If you have 150 hours capacity and you only plan to use 100 hours, you undercommit. That might be your process, but it is not agile.
    – sonstabo
    Commented May 15, 2014 at 6:11
  • Example: check out the green line and comment here: practiceagile.com/2010/02/…. You adapt to change yes, but you adapt by adding the new things to the sprint and removing something else with the same size.
    – sonstabo
    Commented May 15, 2014 at 6:11
  • We commit to stories, not to hours. We can only guess as to the hours; but, our historical capacity in story points can be very accurate. I think you are nuts to demand that the product owner later remove things from the sprint to allow the team to "fully commit" at the beginning, when inevitably tasks are discovered later in the sprint. You are basically assuming the team will never discover work later in the sprint. Instead, I prefer the team to commit to the amount of work they think they can accomplish at the story level and allow the hours to be "undercommitted".
    – Patrick Szalapski
    Commented May 15, 2014 at 13:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.