TFS 2010 ScrumForTeamSystem burndown chart modification

Well, I've been working on adding a total workload measure on our burndown chart, as well as a custom burndown for a subset of team members. A lot of the standard rules are not being followed by the team due to a reluctance to really embrace the process, so there are a lot of items moving between team members, and coming in and out of the sprint, so it has highlighted a few issues in the ScrumForTeamSystem charts.

Firstly, the default burndown filters on "not in" ( "done", "deleted", "descoped") SBTs. This works fine for the standard burndown, as "Done" items have 0 time remaining, so omitting them them simply improves the report performance.

However, adding the 'total workload' to the burndown incorrectly shows a 'drop' in workload when an item is completed, which is incorrect (we only what to drop the workload when an item is removed from the list). Simply adding 'done' items to the burndown list resolved this, so that was easy enough.

The second issue was somewhat more confusing until it 'clicked'. The initial capacity was vastly overstated, so I removed some items from the sprint. The team also decided to swap in some new items to the sprint as well (removing a few others).

After making the changes, I ran the burndown again, and noticed the workload, and work remaining, had risen, despite moving items out of the sprint.

Trying to figure this one out was a nightmare due to the complexity of the report query. In the end, it turns out that the burndown query was filtering incorrectly (possibly to try improve performance).

The way the query should work is that it returns the 'latest work item revision per day', and then checking if the work item is in the sprint (and/or assigned to a specific team member). The way it works was that it returned the 'latest work item revision in the sprint per day' which meant that the revision where it was still in the sprint was returned, so it was still included in the chart.

Once I realised what was going on (no mean feat the way the queries are designed, it took me half the day to figure it out), it was simple enough to fix.

1) Remove the filter that limits the revision list to the specified iteration (so we get all the revisions for each day)

2) add the iteration (and assigned to person) to the revision list

3) when aggregating the 'last revision item per day' items, filter by iteration and person.

All Fixed, now back to getting click-once working on TFS Build 2010 (we have a couple of custom requirements that will be the subject of another post.