Skip to main content

Cloud

TFS Agile Project Management Wishlist

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.
TFS Agile Project Management Wish ListOn 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.

Thoughts on “TFS Agile Project Management Wishlist”

  1. Hi Andy! Are you using source control and/or continuous integration on the project? If so, how’s that working?

  2. Hey Chris! We are definitely using Source Control for all our code, from DB to Cube.
    We are using Database projects for the DW and staging DBs, and using the Project Deployment model for our SSIS code. So far, so good with all of the Source Control situations.
    As far as CI, we are working towards it. We have the DB structures building automatically to our environments, and now we are looking at means of building/deploying SSIS (I am looking at PowerShell), and SSAS (which I have seen done using XMLA and MSBuild scripts). As I’m sure you’ve experienced, SQL Server has been traditionally left in the cold w/r/t Visual Studio and it’s CI capabilities. With SQL 2012 and VS 2012 (with the latest Data Tools updates), that gap seems to be narrowing even more.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Andrew Tegethoff

Andy leads Perficient's Microsoft BI team. He has 16 years of IT and software experience with a primary focus on Enterprise Information Management solutions using the Microsoft Data Platform.

More from this Author

Follow Us