picture of Josh Dzielak in 2016

Hi! I'm Josh Dzielak, writing here about technology and culture. Find me also on Twitter, Medium, Speakerdeck and Github.

How Pivotal Tracker Meets Our Needs

For over a year now I've used Pivotal Tracker on projects to answer the question - "what should I do next?" The tool has worked well for me, and recently I was asked to explain by someone a bit more.. er.. corporate... exactly why it's so great and specifically how it 'meets our needs [being an agile development team]'.

There's a lot of great things I could say about Tracker's features - a slick UI, intuitive navigation, evident emphasis on simplicity and productivity - but today I'll talk about how it helps our team power through everyday situations and successfully meets our needs as an agile project management tool.

In a purist sense, a lean, agile engineering team's "need" is to minimize the time needed to complete each cycle of the observe-orient-decide-act product development loop. Put simply, we need to build, learn, respond, build... (repeat) as fast as possible. Here are some specific ways that Tracker helps us keep that loop tight.

Add bugs and stories fast during collaborative team testing sessions

To maximize productivity during rapid test-a-thons, logging stories and bugs must be effortless. Requiring more than a field or two to create a story interrupts use-case workflow and can cause a tester to lose their place, become fatigued, or wose - encourage a 'log it later' or 'it's close enough' attitude.

Pivotal Tracker stories require only a title to create. Stories can be augmented easily with descriptions, comments, and attachments after creation without tediously waiting for full page loads a la traditional tools. This encourages more attachments, more comments, and more refined descriptions through iteration.

During aggressive testing sessions, it's not uncommon for testers to find the same bug at the same time. Because the Pivotal Tracker UI updates in real time, a user can see stories pop-in instantly as they are added and adjust their inputs accordingly. The result - fewer duplicate stories = less time lost.

Change product priorities without disruption

Tracker allows on-the-fly, drag-and-drop story ordering to change the priority of items in real time. Product managers are empowered to update priorities instantly based on user testing, customer feedback, and even organizationally disintermediated synergystic imperatives.

Tracker's UI makes it clear that developers grab their next story 'from the top' - i.e. the top of the product team's priority-ordered story queue. No extra communication or disruption need take place when priorities change - as developers pick up new stories they'll consume updated priorities.

Understand the current iteration's progress

Tracker's UI encourages product managers and developers to author and report on stories at a granular level. The entire team can see cycle progress at a macro level and also within specific stories by reading up-to-the-minute comments and tasks. This is especially crucial when ordering priorities during crunch time as the next deployment target approaches.

Estimate predictably

Development cycles become predictable over time as development and product teams learn to consistently estimate in terms of  'points' - arbitrary but consistent units of story size or effort. Tracker keeps your mental model simple by constraining point values to the following: 0, 1, 2, 3. Stories too big to fit should be broken down until a point value can be assigned.

During the time I worked with Pivotal as a client, we saw teams assign different meanings to specific point values - e.g. is a "3" [point value] a day's worth or a weeks? - what mattered for each team was sticking to the same value assignment consistently. Over time, this makes stories and iterations *actually* predictable.

This approach side-steps the difficult issue of true software time-estimation. It lends itself especially well to projects with fluctuating requirements or priorities. Instead of a large amount of 'estimation work' being done once and then rendered invalid by changes, the estimation exists as a a living, breathing part of each iteration, updated on the fly. (Tracker lets you know right away when re-prioritization or re-estimation pushes other stories out of the current iteration.)

Align to environment workflow

Story states map naturally to our environment promotion strategy. When a developer pushed code for a story, he/she marks it 'Finished'. Finished stories are promoted to demo/test/integration (whatever you like to call it) and marked 'Delivered'. These stories will then be 'Accepted' or 'Rejected' as each are tested. Accepted stories are ready for inclusion in a production deployment, and Rejected stories are returned to the development queue to be fixed. The natural relationship between story states and deployment saves time and reduces miscommunication and error.

Yes, we might be fanboys of Tracker. But hopefully I've laid out a little bit about why we are and will continue to be in the foreseeable future.