My Old IIS.NET BlogTechNet Magazine Articles Learn about IIS7 from a book I wrote a few years back!
Blogs I Read
If you spent some time reviewing my blog on how to build a “reporting” dashboard that shows status of your development projects you will notice quickly that is a real nice way to review your work in your daily Stand-up. It gives you the ability, within 30 minutes (default for TFS warehouse/cube sync), to see progress of your project(s).
There are some projects that include not only just “work” which is assigned to developers, testers, and PMs in the form of a task. The tasks allow you to get original estimates, remaining work, and lastly completed work. If your project includes bugs then you will quickly learn that it doesn’t include estimation capabilities on the bug work item type. This isn’t a problem if you followed my blog that showed you how to edit the Bug work item to add estimation capabilities for your team.
The first thing you will notice after you modify the Bug work item template is your Burndown chart, rate, and remaining work doesn’t include Bugs. This is expected because, by default, no report includes both tasks & bugs. This is doable but you have to do some work and trickery.
As to an example, lets take a look at the default burndown report for a project in the below screenshot -
This is a great view of the “state of affairs” for the project if you are always creating a task that is linked to any bug that is found. However, it fails often to give a complete view into the project if you have bugs in the products/features that you want to accurately track in your burndown. This is easily viewable in the above report by changing the work item type (which is by definition multi-select) to include Task & Bug as shown below -
In the first screenshot, the project had less than 100 hours of work remaining on the sprint to end June 26th. However, when including bug estimated work as you can see in the 2nd screenshot then the hours shoot up to near 200 hours. This is valid to track in your project to get an accurate burndown, right?
Unfortunately, if you play around a bit with the report parameters associated with burndown/remaining work you will quickly realize that getting your dashboard view to show both task & bugs isn’t trivial. The first thing you might think is to edit the report by exporting it but let me just share with you it will not work – the report wasn’t built with that in mind. With that thought out of our mind, the next thing to pop in your mind is to just show the report directly on your dashboard via TFS’s query string capability. What I mean by this is taking the string provided in my first post and adding something like the following to it -
/sites/[collectionname]/[projectname]/TfsRedirect.aspx?tf:Type=Report&tf:ReportName=Project Management%2fRC2 Remaining Work&tf:ShowToolbar=0&Width=250pt&Height=180pt&WorkItemParam=Bug&WorkItemParam=Task
I’m sorry to say you will again strike out. In fact, you will probably recognize that the report will return errors. Are you stuck?
With the help of John Socha, I was able to finally figure out how to take this beautiful report shown above and place it in the dashboard that would give us one place to see how things are progressing on our multiple projects. This wasn’t as clear cut as I had hoped and I was quickly realizing that option 1 & 2 I listed above wasn’t going to work. John helped a bit by realizing that report server is very, very peculiar about how the parameters are passed to it. In fact, if you attempt to use the tfsredirect.aspx the report will still fail everytime. Instead, you have to set the report to be a dashboard (Is Dashboard) and set the width/height along with special values for the WorkItemParamType like below -
As you can see, you have to include escape characters (%5b, %26, etc.) in order to query Reporting Services properly and get back data. With this nugget of information, we now have a solution to getting dashboards to work properly for both tasks and bugs.
With this information included above, we are now able to edit the Webpart for the dashboard to show the current progress for our sprint. To do this, here are the steps -
You should keep in mind that various reports will have varying URLs but, as an example, you can use the following as a sample of a working dashboard report that includes bugs & tasks for the burndown rate under project management -
The key piece of information is to the WorkItemTypeParam and now you get data that shows in a dashboard that includes both bug and task like below -
In this post, I shared with you a bit of information about how to expose reports on your dashboard that include both task & bug completed/remaining work. This allows you to easily, with the team or management, determine the current rate of work in hours remaining based on estimations made during Sprint planning or during the sprint as bugs crept up.