TFS vs PivotalTracker

20. October 2011 Uncategorized 0


I first saw this cartoon about 3 years ago while we were in the midst of an SAP migration, as well as 2 other internal apps being rewritten. I was the lead (okay, time to be honest, I was the only) developer on one of the apps, that sadly looked  a lot more like image #3 than the other 2.  But the cartoon resonated with me, and challenged me to make software more usable.  I’d largely forgot about the image until I started thinking about ALM software.

Why does ALM software make me think of this cartoon?  Because there appears to be 2 types of software for managing your project. 

  1. Software that exists for all non-developers to know what’s going on and track the progress.
  2. Software that exists for all developer teams to help them get the development done faster.

Number one tends to look a lot like the “You’re company app.”  Number two above, while not quite like a Google or Apple app, is far enough away from the “You’re Company App” that it by default goes to the Google or Apple camp.  Let’s take a look at some screen shots.


The first ALM that I’d like to look at is TFS.  I use this software every day.  I’m told that we’re actually using a third party template.  Here’s the screen I’m greeted at when I pull up the “My Work” template:


Here we see a slew of data at the top in a grid format.  Some of this data is repeated down below.  If it looks like there is missing data, it’s because I tried to delete anything specific to the project.  Of the 9 fields below, I ignore 8 of them (I change the “Current Status” and that’s about it.)

After I’m done looking at the main screen, perhaps I want to drill down into more detail on a specific item.  That’s where the next image comes, the “detail view” of TFS.


Here we see even more fields that I ignore as a developer (ROI, Project Billing etc.)  The way we end up using TFS, 95% of our content goes into the “Description” tab.  We seldom, if ever, use the “Tested By” or “Impeded By” tabs.  And the only time I look at the history tab is so I know who to be mad at for assigning me this work item (mostly kidding.)

From the looks of these two screen shots, it’s appears that this template is great for tracking a million different things, and oh yeah, we can squeeze some information in there about the work that needs to be done.  But more times than not, I look at this as a hindrance to my work and not a help.

Pivotal Tracker

To contrast TFS and it’s “ALM Model 1” behavior, let’s take a look at Pivotal Tracker.  I’ve used this for a little while now on a side project that I’ve been doing for my sister.  I’m the only developer in this scenario, but have talked to teams that are using this.  Let’s start with how you’re greeted when you enter a Pivotal Tracker project.


There are still a lot of options that I ignore (Profile, Reports, etc.)  But now they’re moved out of the way to the upper right.  Even the buttons underneath “Brutal Spider” are discreet enough that they’re easy to ignore. What we’re greeted with here is 3 columns of data.  My work.  Items in the backlog, and Items that are done.  You could also add some more columns using the buttons at the top, but for my use this is plenty.   The “My Work” column contains a list of items for me to work on, and only has their title, status (Start button means “Not Yet Started”) and a quick estimate (the blue bar on the left.)

Once I want to work on a particular item, for example, the second one, I can click on it to get the details as seen here:


This now tells me everything I need to know to get the work done.  It has who should be doing it, a field for an additional description, fields for sub tasks, and a space for uploading files.  In all honesty, it has a lot (but not all) the same data that TFS does, it just presents it in a cleaner way.  Most of the time, I don’t even expand the story, because I know what to do from the title.  But in the case where I need to, the additional description is helpful.

As I move this card from in progress to ready for test it moves into the different columns.  When it’s done and released, it drops out of site. Remember, these cards are supposed to exist to help developers get work done.  We don’t need to hold on to them for years and years (or even months and months) inside a database.  That’s not the purpose of issue tracking software.