TFS Agile Project Management Wishlist

The IT Leader's Guide to Multicloud Readiness

This guide provides practical key insights and important factors to consider to make informed decisions in your multicloud journey.

Download the Guide

For several months, I’ve been working on a DW/Reporting project which uses Team Foundation Server (TFS) 2012 for Agile project management.  This has been my first experience using that aspect of TFS, so I’ve been alternately surprised, annoyed, gratified, accepting — I’ve run the gamut of human emotions dealing with this tool.  I’m a longtime user of TFS as an integrated source control/dev process tool, and I think it’s wise to incorporate this Agile management element into it.  Reminds me of the old CASE tool days.  But having cut my Agile teeth in a world of open source tools like JIRA and Confluence, I can’t say I’m 100% satisfied in what TFS brings to the table.
On the whole, the JIRA and TFS workflow and organization are equivalent.   The basic Scrum-oriented workflow, creation of Backlog Items and then tasks for those items, task linking and relationships, resource management and sprint-level capacity planning — these are more similar than they are different.   There are some terminology differences (“PBI” = “Story”, “Feature” = “Epic).   And obviously, the user interfaces are different.  TFS uses SharePoint 2013 for an online interface — which is a boon to me, as I have become a native SharePoint user over the years.  I can definitely say it was a lot easier to get my hands dirty in TFS than it was to learn JIRA.  I’m sure for anyone having gotten used to one, moving to the other will be an adjustment.  But you can get the drift pretty fast.
Other differences, however, constitute feature and usability gaps that are pretty painful.  Here’s some steps that might improve the usability of TFS (and maybe get me to stop wanting to beat it with a hammer):
Use the PBI Numbers more prominently – JIRA somewhat forces you to accept and use the item numbers it generates for Backlog stories and tasks.  I resisted them at first but I came to realize how nice it was to have a specific shorthand for any given PBI.  We provided links to a given Story in an email, sometimes just mentioned the number, and all was clear.  TFS provides numbers but doesn’t show them by default in the Backlog.  I think they should.  I have noticed that we have spent a lot of time trying to find PBIs or clarify which PBI we are talking about.  This is starting to seem like maybe a process thing that I should initiate….
Basic totals and counts – I find it harder than necessary to get meaningful metrics like Effort Points per Sprint, or counts of PBIs per Feature, etc.  Yes, these metrics can be derived through the Reporting page.  But that’s lame — these are pretty basic measures which should be available by default.
Improved Backlog views – Basically, I find the navigation around the various necessary views of the Backlog to be unintuitive.  So my two big suggestions to improve it are:  Sortable Table Headers and More Explicit Hierarchy View Toggling.   Not being able to easily sort backlog in order to find a particular PBI is just awful.  If I had a dime for every minute I’ve spent visually scanning a screen for a particular record…   Let’s just say that any time you show data in a table, you should provide sorting functionality.  Duh.  And I’m not digging on the little colored rectangles in the Backlog to show/hide Tasks, or divide the Backlog into Features.  I think the toggles for these things should be more obvious.
Automatically mark a PBI’s “Done” when all its child Tasks are “Done” – Again, this is kind of a no brainer.  I can see some little points of process maybe contradicting this, but my argument would be that if all the Tasks are done, then the PBI is done.
To be clear, these are nitpicks.  We’ve been quite successful at managing our project with TFS as it is.  But after running about 20 sprint planning meetings conducting the team through the backlog, I feel like these items would make a huge difference in usability.