12 Tips to Get the Most From Pivotal Tracker

With a tool as powerful as Pivotal Tracker, it can sometimes be tough to wrap your head around how to use it to your best advantage. And while we don’t pretend that we have all the answers, the time we’ve spent getting deep down and dirty with Tracker has given us a good vantage point from which to suss out the better practices from the... less better ones.

Here, then, are what we consider some leading practices for getting the most juice from the Tracker fruit, and for Agile success more broadly.

1. Pivotal Tracker Is Not a Replacement for Communication

Language is fluid and subject to interpretation, so try not to use a Tracker story as a stand in for a conversation. Consider doing a design walkthrough of a story or project with support and testers, so they can help with different perspectives on usage and customer requests.

Are your story comments stacking up? Get people together briefly to go over the issues, then update the story with the key points. Discussing issues in person can minimize misunderstandings that can too easily become a distraction or time sink.

2. The Team That Writes Stories Together Succeeds Together

Whenever possible, customers and developers should write stories together because a story is both a customer business value and a developer deliverable. In this way, everyone’s interests and viewpoints can be shared and aligned.

3. Plan for Success

Conduct a weekly iteration planning meeting so the team can review and estimate upcoming stories. Develop estimates as a group, so everyone can be heard. To make the process lighter, you could play an estimation game. We do not suggest Settlers of Catan for this. Instead, try something more like Rock, Paper, Scissors.

To estimate a given story, have each team member toss out fingers—in line with the estimation scale you’ve chosen—to indicate their suggestion for story complexity. Did everyone estimate the same? Great! If not, begin a discussion and estimate the story together.

4. Go Small

Create stories that are incremental and focused on the perspective of the user. So if you need to repair a brick wall, try to focus on the user’s interaction with a specific aspect of the wall, not the entire wall itself. The story, “Wall should be in good shape,” would be more useful as, “Passer-by should not see visible cracks in wall.”

5. Try to Avoid Large Estimates

At the same time, some stories will be grander in scope or more complicated despite your best intentions. You should still try to minimize this and reserve the practice only for stories of unclear or enormous scope, and then break them down. Otherwise, an estimate of 8 (based on the Fibonacci scale) is a cry for help.

As a developer, you should ask for clarification and look for seams where the story can be broken down into multiple stories.

6. Name a Tracker Czar

Steering the ship while simultaneously fixing a leak is a challenge, to say the least. To that end, you should have a Tracker Czar, who shouldn’t also be coding in the project they own. Owning a project is a lot of responsibility, but it makes a huge difference.

7. The Customer Should Prioritize Stories

While it’s true that anyone can create stories and put them in the Icebox, only the customer (or a PM acting on behalf of the customer) should prioritize them.

As the business owner, part of a customer’s decision-making process is to decide which features have priority over others. In other words, the customer should be making the hard choices.

8. Turn Chores Into Feature Stories

Turning chores into features reframes them as items of direct and verifiable value to both the end user and project goals. This could simply be a matter of rephrasing the story, or arguing more strenuously for its business value.

9. Accept and Then Move On

Never restart an accepted story; instead, make a new story or bug. It's cleaner, you can keep new information more focused, and it doesn't detract from the work that's already been done. You can always paste in the URL to the original story for context.

10. Reject With Class

Rejecting a story with both tact and clarity can be challenging, but there are some strategies to make it go more smoothly.

If you’re not onboard with a given feature or story, prefix your comment with “reject:”—it’s easier to scan and figure out which comment is related to the rejection.

11. Don’t Reject a Story if It’s Missing Criteria, or if You’ve Changed Your Mind

After all, there could be more here than meets the eye. Again, have a conversation. Reassess what’s missing and make a new story; don’t just reject it without knowing all the details.

12. Move Rejected Stories to the Top

Location, location, location—it’s of paramount importance. Move a rejected story to the top of the active group in the current iteration. When developers look to see the next story to work on, they’ll see the rejected story as the next to pick up.

Even if there is no verifiably universal way to use Pivotal Tracker for Agile development, and though it can accommodate a variety of approaches, time and experience have proven to us that some practices make more sense.

If you have questions or feedback for us, we’d love to hear from you! Please visit our websitefor more information, or contact us at [email protected].