The Tracker Story…

Pivotal Labs is a consulting shop and not a product company, so it might seem odd for us to release a product like Tracker. We didn’t build Tracker for the sake of building a product; we needed it.

State of the art: index cards

We’ve been doing agile software development before terms like “Agile” and “XP” existed. Over the years we’ve made numerous attempts to use the variety of software project management applications available, from Microsoft Project to the more current agile-specific products.

We kept returning to index cards, sometimes augmented with a patchwork of wikis and spreadsheets. We followed the agile planning tools out there, but each attempt to adopt an one resulted in frustration. Configuration and data entry were a constant expense. User interfaces were clunky and had too much back and forth navigation. The workflows were inefficient and the overhead was high. (We kept hearing circus music in our heads, with all the hoops we were jumping through.) The usage cost never seemed sustainable. It always felt like we were working for the product, instead of it working for us.

But we needed something…

As our business grew, so did our frustration; index cards were far from ideal but the alternatives were worse. And at the same time, we were just starting to look at a promising new technology, Ruby on Rails. So we decided to build our own tool.

We started working on Tracker in late 2006. Its beginnings were very humble. All we needed was to have a backlog and be able to easily prioritize. We created simple story editing and built drag-and-drop prioritization and we were ready to start the switch from index cards. (These simple features gave us parity with index cards, with the bonus of having the backlog online.)

Who gets excited by project management software?

We started using Tracker on all of our client projects. We continually improved and tweaked the application, integrating our experience and feedback. And we started to find that it really transformed both the transparency and the flow of development.

Tracker quickly developed a following among client developers who had used it when working with us, too. We would routinely received requests for accounts: “I used Tracker at my last job. Can I have an account to use in my new one?”

We would always accommodate these word-of-mouth, friends and family type requests. Entire client organizations, beyond our projects, started using Tracker. The interest continued to grow and with much greater enthusiasm. We kept getting emails saying things like, “Please let me pay for Tracker; I can’t live without it.”

So we decided to make Tracker publicly available. We launched the public beta at RailsConf 2008. Over 10% of the attendees signed up that week.

Why Tracker is Special

We had three key insights at the outset that made Tracker work:

1. the user interface needed to be simple.
2. The project status and backlog needed to be easily (always) available.
3. You shouldn’t have to constantly plan iterations.

The first point is simply about good UI design, but it’s amazing how many tools out there get this wrong.

The last point is more subtle. In agile processes, particularly XP, there is a concept called velocity. The basic idea is that you assign a point cost to stories and the sum of the point costs of completed stories in a given iteration is the velocity. You then use the velocity to project how much you will be able to get done in each future iteration. As teams start to gel, they exhibit a strong central tendency to get a consistent amount done each week, and this velocity becomes extremely predictive and reliable.

Traditionally, after completing an iteration, you would re-plan each subsequent iteration, adjusting for the actual rate of progress. This can also be onerous, but it’s critical, as it is allows you to project when each milestone will be reached. The feedback needs to be taken into account so better-informed decisions can be made.

The solution is the emergent iteration. Pivotal Tracker automatically (and in real-time) tracks story completions, iterations and velocity and will dynamically adjust iteration backlogs based on actual progress; Tracker does the grunt work and your project schedule is always up-to-date.

The Tracker Philosophy

Tracker embraces simplicity. It should make managing projects easy, rather than make its users slaves to maintaining the plan. It should give every user of the system more information back than they put in.

Tracker doesn’t have a huge list of features, because it tries to stay true to its core purpose. (Remember, it exists partly because of our frustration with the bloated alternatives.)

At times, Tracker appears opinionated as it can place strict limits on how you manage your project. But this is a consequence of its focus and the interdependence of features; the sum of Tracker is far greater than its parts.

While we don’t always get it right, we try to make sure each additional feature or product change adds a lot of value and makes users’ work easier.