Pivotal Tracker > bug trackers

Posted by Jon
on Monday, February 02

I’ve used just about every defect tracking system there is. That includes Trac, Fogbugz, Lighthouse, a Rails-based Trac clone that I forget the name of, spreadsheets, note cards, and even Bugzilla. I haven’t tried Mingle, and I only used Jira for a few days, but I’ve got most of the other bases covered. Last year at Tumblon, we settled on Fogbugz as less painful than the other options. It’s a pretty good defect tracking system, with most of the right features, and it’s reasonably easy to use.

A month ago, I tried Pivotal Tracker for a new project. It blew everything else away.

I think there are two reasons for this.

First, it’s a story tracker, not a defect tracker. And when I’m building software, I need to track stories more than defects. Of course, Pivotal Tracker handles both, and so do most bug trackers. But bug trackers usually seem natural when I’m using them to track bugs, and unnatural when I’m trying to map out new development. Pivotal Tracker feels natural for both.

Second, it prevents sabotage. This is the real key. Software development projects are hard to get right. It’s really easy to unintentionally sabotage a software development project, and everyone on the team can do it. That’s why there’s a huge publishing and training industry around project management, and why most of us are interested in the software development process. (Things like Agile, XP, and Scrum) are probably interesting to you and I, while CMM and CMMI are interesting to other people.)

Basically, Pivotal Tracker enforces a lightweight agile process, and makes this painless. If you use Tracker properly, you’ll write relatively atomic stories, estimate their difficulty, prioritize them, step each one through a simple workflow from new to accept/reject, track weekly or bi-weekly iterations, and see where you’ve come from and where you’re going. You can do this with most bug trackers, but most of them are missing one important thing.

Constrained velocity.

Pivotal Tracker requires that every feature get an estimate on a simple scale – 0-3 is the default. These are relative velocity points, not hours, and they give you an idea of how much you can accomplish in an iteration. After your first iteration, Tracker uses the average velocity of the previous few weeks as the predictor of your velocity for the current iteration. So if you did 17, 15, and 20 points over the last three weeks, Tracker thinks you can do 17 points next week. Chances are, this is a decent guess.

The Current Iteration and the Backlog are a continuous list in Tracker, and the line between them is based on velocity. If you only have 12 points of work on an iteration, you can’t add stories to the next iteration – you still have capacity on the current iteration, so the stories will show up there. If you have 17 points scheduled for this week, and you try to add 2 more, something has to give. And this is the key.

By managing velocity in this way:

  • The product owner can’t shove an extra 5 points of work on an iteration just because he wants it to get done, at least not without recognizing that it will take more resources (i.e. more programmers).
  • The product owner can’t make every new feature the top priority just because it is new, at least without clearly seeing that other features will be delayed.
  • Developers are forced to estimate everything. You can’t start/finish/deliver a story until it has been estimated first. As long as estimates are optional, they won’t be done consistently.
  • Everyone has a decent idea of how much can be done over time. The velocity estimates aren’t perfect, of course, and that’s just fine. They don’t have to be perfect – they just have to be Good Enough. (For what it’s worth, our velocity over the last 4 weeks was 20, 15, 16, 17 – good enough that we can expect to do around 15-20 points/week.)

There are also some smart touches. For example, you can set the team strength for a given iteration – if half your team is going to be pulled off onto another project next week, or out of town at a conference, set the iteration strength to 50%. Tracker will halve the expected velocity. Or if you have another developer you can pull onto the project, increase the strength to 125%.

Of course, Tracker isn’t perfect. It isn’t particularly client (Product Owner) friendly; I’d love to see a dumbed-down interface that is less intimidating to non-technical clients, but still has all of the features that they need (prioritization, Accept/Reject). And I’m not exactly sure where the QA role fits into the process – there is no “Verified by QA” state, so QA either needs to usurp the Accept/Reject role, or needs to be responsible for Delivery (deployment).

I’m also not sure how well it will work on large/long projects. After 4 weeks of work, we’ve added a total of 250 stories to the system, and 100 are still active (unfinished). It’s working fine now. But if we had 6 months of work mapped out in the Icebox, it might be a little hard to find things.

But Pivotal is actively working on improving Tracker, and even if they weren’t, it’s already better than most bug trackers.

Comments

Leave a response

  1. grosserFebruary 02, 2009 @ 11:16 AM

    I really like tracker, it gives great feedback to the developers and all people that want to push in new features.

    PS: Id recomend you remove the “OpenId authentification” step and replace it with “RPX authentification” http://pragmatig.wordpress.com/2009/01/23/openid-is-complex-and-limited-use-rpx

  2. Mike SubelskyFebruary 02, 2009 @ 11:18 AM

    Jon, this is great to read. We picked FogBugz for the same reason (great for defect tracking, lesser of most evils for story tracking) but we are frustrated in trying to plan new features. I’ve been dabbling with Pivotal Tracker and have been similarly impressed. Hearing your experiences increases my confidence level. Thanks for the write-up!

  3. Will LeinweberFebruary 02, 2009 @ 03:03 PM

    With regards to how it works for long term projects: I’ve used tracker for two months just as an exsistng project moved to it from Trac, and it was great then. I came back on a year later while they used it for the year I was gone. It was still great. Easily the my favorite tool, and I was very happy when Pivotal opened it up so I could use it for my own stuff.

  4. NapoleonFebruary 02, 2009 @ 07:55 PM

    Pivotal Tracker is a fantastic tool, especially when paired with a story/feature grammar. While working on relatively complex projects, I’ve settled on a grammar like this:

    Who the user is, what the user can do, and why they want to do it

    So to borrow from your screenshot, the story might read something like this:

    A logged in user can see their username in the header, because knowing if you are logged in improves usability.

    The more obvious the reason behind the feature, the more tedious it is to write the why in a user story. This has an interesting side effect of helping to identify what are “expected” or “mandatory” features of the site.

    Late in a project, when you’re deciding which features to throw overboard, it can be very helpful to remember why you really wanted that feature in the first place. If the focus in a project has changed, it makes weeding out the scope much easier.

    Deciding on any grammar related to chores can be extremely helpful when dealing with many developers and stake-holders in a project. Often times it is difficult to explain what a developer is working on, because their chore is highly technical. With a grammar that includes the “because clause” on every chore, a developer has a chance to explain in plain English what “configuring the XSS terminate” means to their manager.

    Finally, I would suggest looking into how you can reuse the user stories that you create in Pivotal Tracker. They are very reusable as the titles of tests in your code. And they can also be helpful when trying to determine priority through the Kano Method.

  5. Jon DahlFebruary 03, 2009 @ 10:24 AM

    Thanks, everyone, for sharing your experience!

    Napolean: what you’re describing sounds like something that could fit in perfectly with Cucumber and the like. Ever seen anyone do this programmatically?

  6. JohnFebruary 03, 2009 @ 01:04 PM

    Another alternative worth considering is Intervals. Though it’s web-based it is ideally suited for web development teams and flexible much in the same way as Pivotal Tracker.

  7. AlokFebruary 04, 2009 @ 05:19 PM

    Is this open source? I would rather use free software than commit to closed doors.

  8. Chris BlowFebruary 04, 2009 @ 10:00 PM

    It’s not open source (agreed: Pivots make it FOSS please!) but i have used it for more than a year and i can’t imagine using anything else. It’s extremely well done. Powerful and simple.

    I only wish that it had better support for images (like an architecture diagram).