Outgrowing Pivotal Tracker
At Salsita, we've been using Pivotal Tracker as our primary project management tool for over two years now. When choosing...
Table of Contents
At Salsita, we've been using Pivotal Tracker as our primary project management tool for over two years now. When choosing a tool, we were looking for something generic enough to use both to present a project overview to clients and to manage developers' day-to-day work.
We've tried various solutions, but in the end we settled on Pivotal Tracker, which has a lot to like:
- It looks good and it's easy to use, i.e., doesn't have too many settings and/or strange buttons or dropdowns. We value simplicity, so that's a big plus.
- Excellent API & support for webhooks (i.e., push notifications). That's particularly important to us since we're using our own tools to facilitate our workflow.
- It's opinionated. Which is a good thing... until you find out your workflow is not a good fit. More on that below.
- Motivates you to describe features as user stories which we find very useful.
So overall speaking, Pivotal Tracker is a very solid product that has been a pleasure to use. However, as the company grew and our workflow gradually evolved, a laundry list of things of annoyances started to build up. And two years later, it's really dawning on us the bad parts may just be more relevant to our workflow than the good ones.
Here's what we find lacking in Pivotal Tracker:
PT features can only ever be in one of six states:
rejected (even less if your story happens to be a chore). Do you want to add custom states? Tough luck.
No bug/story dependencies
Pivotal Tracker distinguishes between bugs and features, giving the impression it's meant to be used as a bug tracker. However, it lacks one of the crucial aspects of a good bug tracker: story dependencies.
Like it or not, bugs are usually connected to features. If you add a new button to your app and the app crashes when the button is pressed, a bug should be filed and linked to the "add button" feature.
Sadly, Pivotal Tracker does not support dependencies. You can't say "bug #42 blocks story #36" (other than in a comment) and you can't prevent that story from being accepted based on that knowledge. This makes Pivotal Tracker pretty much useless as a serious bug tracker.
No custom views
Pivotal Tracker is client-facing: you have a list of stories and a clean UI to present them to the client so they can see what's been done in the current iteration and what's scheduled for the next one.
Well, in theory.
In real world, any bigger software project invariably comprises a number of low-level technical stories, be they refactoring or fixing bugs in the "plumbing". And unless you can filter those out (e.g. by presenting a custom client view) they will eventually clutter your nice client-facing UI and make it hard to understand what's going on.
Unfortunately, Pivotal Tracker doesn't offer a way to do that. Unless you offload the low-level technical "uglies" to a different tool, you can't present your client with a clean summary of the project state. You might end up with an iteration half-filled with little refactoring stories and technical bugs which the client doesn't really understand and/or care about.
All things considered, Pivotal Tracker is a nice tool. For small agile teams with a fitting process (no dedicated QA, no code reviews etc.) it can definitely do the job and do it well. However, at Salsita the general feeling is that we've outgrown it; the rigid process it imposes is too constraining for our evolving needs.
We're currently looking for either a supplement or a replacement to Pivotal Tracker. We're considering various options, the most promising being JIRA Agile (nice Kanban view, good API) and sprint.ly (nice API and custom views).
We'll keep you posted.