This is how I use Pivotal Tracker.
This is the first article in a new collection, This is how I SaaS. As a product designer, manager, and now owner, finding the right SaaS tools to get the job done for my team has always been a laborious task. Rather than sifting through documentation, videos, and trial periods, I’ve always wanted someone to just show me how they use it and see if it aligns with the way I like to get work done. That’s the goal of this collection: personal endorsements of the SaaS tools we use and love. I look forward to hearing how you SaaS.
Five years ago, I was first introduced to the tool Pivotal Tracker (thanks, Jesse!). It was my first time using any type of story-based project planning tool. Since then, I’ve experimented with many of the usual suspects: Trello, Jira, Redmine, Asana, Sprintly, Basecamp. But I never found a tool that matched my expectations quite like Tracker did.
Which is why when it came time to select a tool for us to use at Notion, I had my heart set on Tracker.
If you’re not familiar with it, here’s a brief summary taken from Tracker’s site:
Tracker is a story-based project planning tool from Pivotal Labs that allows teams to collaborate and react to real-world changes instantly. It’s based on agile software methods, but can be used on a wide range of projects.
Tracker maintains a prioritized backlog of project deliverables, broken down into small, estimated pieces, called stories. It dynamically groups these stories into fixed segments of time, called iterations, and it predicts progress based on real historical performance (velocity).
The Setup
While most users of Tracker are probably development teams, we actually run each of our business units through it. Thus, we have five individual projects under the same account: Dev Work Log, Operations, Growth, Product Roadmap, and the Island of Misfit Stories. I’ll explain each in detail further down.
Tracker has a Workspace feature where you can show panels from multiple projects in the same view. For example, my main workspace shows me the Current/Backlog panel for the Growth, Dev Work Log, and Product Roadmap projects as well as the Ice Box for Dev Work Log and Product Roadmap. 95% of my time in Tracker is spent in these panels. When I need quick access to any other project panel, I can simply turn it on and off from the side panel.
If you run multiple projects or teams, Tracker’s workspaces will save you time, keep your teams aligned, and prevent headaches down the road.
It’s worth noting that workspaces are unique to each user, so I highly recommend finding a workspace setup that works for you and help your team members set one up if you need them in the same view.
Notifications
With this many projects and tickets flowing through Tracker, you can imagine that a lot of notifications are sent. Thankfully, you can turn off email notifications and integrate with Slack, both of which we have done. (Side thought: I wonder if the day will ever come where Slack is enabled by default in SaaS tools and you have the option to turn on email if you want?)
I recommend taking a look at the Slack integration settings and only enabling the notifications that you want.
Since not everyone spends as much time in Tracker as I do but everyone is constantly in Slack, pushing notifications there has been an efficient way to keep everyone in the loop and to raise awareness on issues faster.
The Dev Work Log
The dev team effectively uses the tool as prescribed. Our project contains the features, chores, and bugs that we are responsible for delivering every two weeks. Every other Monday, we run a sprint planning where we review the stories in the backlog, estimate the level of effort until we’ve satisfied our expected delivery based on velocity, and then we get to work. Nothing out of the usual for the dev team.
Tracker also has some great charts that I use for at-a-glance insight into how our team is doing. (Full disclosure: our product integrates with Pivotal Tracker, so I check most of our analytics in our dashboards in Notion. If you’re interested in details, shoot me an email at kevin@usenotion.com.)
The one I reference the most for the dev team is the Iteration Flow. For us, a healthy sprint is one where stories are delivered and accepted at a consistent pace and only a few stories are being worked on at a time. That means a consistent climb of green columns, small columns of yellow and blue, and NO red. :)
Reviewing these charts at the end of a sprint helps visualize any problem areas that we can address in future sprints.
The Product Roadmap
In the past, I’ve been on teams where PMs have used Basecamp, Aha!, Asana, and good ol’ Excel docs to manage the roadmap. While each of those tools have their benefits and use cases, my biggest complaint has always been that they feel removed from the dev tools. Yes, some integrate directly with ticketing tools — but the fewer steps the better when it comes to gettin specs into the developers’ hands.
So to reduce the number of steps, I’m running the roadmap directly inside of Tracker and it’s been working amazing.
The Product Roadmap’s icebox is organized using release markers that group features by theme. This makes it easy to move entire chunks of stories at a time and allows us to quickly visualize how much we might be cramming into a sprint. Because as we all know, roadmaps change frequently and trying to reorganize and maintain a spreadsheet is hellacious.
When it comes time to define the specs and user stories for a feature, we move stories through Tracker just like we do dev tickets. Start a ticket to indicate you are working on it. Finish a ticket to indicate you have completed the specs. They are then reviewed as a set and marked as Accepted to indicate they are ready for development.
Next, I select all the Accepted stories, duplicate them, and move them to the backlog of the Dev Work Log project.
(I duplicate them so the timestamp of the stories in the work log resets. We track specific metrics around cycle times for the stories. Duplicating allows us to track them individually across each project.)
By keeping undefined features in the product project and defined/spec’d features in the dev project, it reduces the clutter and lets the dev team have visibility into what is coming up next with more certainty. It also allows us to easily see what specs are being defined and worked on without it effecting the dev team’s velocity and throughput calculations.
Roadmaps change frequently and organizing them in spreadsheet is hellacious. Doing it all in Tracker has been a life saver.
Related to the Product Roadmap project is the Island of Misfit Stories. This is simply an extra icebox where we keep stories that don’t currently fit into the roadmap but we also aren’t quite ready to delete them yet. Since Tracker doesn’t have any way to archive tickets, this is our temporary solution and seems to be working fine.
The Growth and Operations Projects
Since we have been having such success with the roadmap in Tracker, we decided to run the growth and executive teams through it as well.
The growth team runs sprint planning every other Monday as well, but the sprints overlap with the dev sprints by a week. And like the dev stories, we create user stories and specs for each task we are trying to accomplish in the sprint. It’s a great way to stay on track and align with the rest of the company when features overlap. It also keeps us focused on marketing efforts — where tasks can often spiral out of control if you let them.
Similarly, my co-founder and I have an Operations project that only we have access to. Here we include any tasks to get done as it relates to running the company.
Conclusion
Hopefully that gives you a pretty good understanding of how I use Pivotal Tracker with my team at Notion. Some of it may be a little unorthodox, but the beauty of Tracker, in my opinion, is that it’s designed for agile teams but is flexible enough to accommodate your own approaches as well.
If you have any questions, suggestions, or notice any typos feel free to list them out here. I’m happy to explain more. And if you are interested in contributing to This is how I SaaS, please do so!
