A radiography for Pivotal Tracker

This is a bit of a follow up for Easy Gamedev Planning – The Agile Way

I am a big supporter of planning, especially for game projects which are always so messy and hard to control. But the truth is, planning and project management is hard and takes time. Sure, its fun, but it’s a reliable, long term, mature kind of fun, incomparable with the instant joys of – say- design or art.

So for Heart. Papers. Border., our planning strategy failed miserably. And we ended up with a very confused project AND mind. When you don’t plan, feature creep is a certainty and the scope becomes just a messy blob of “Wow wouldn’t THAT be cool, LETS DO IT!”, followed by the sobering “What the bip was I thinking?! I don’t remember… Probably because I wasn’t thinking anything”

Our commitment to have Heart. Papers. Border. see the light of day brought us naturally back on track. We started writing tasks on PostIt notes and refusing to add on top of an already bloated wishlist. We talked about the core values of the game and the minimum set of features we need to showcase our idea. We designed alternatives to fake systems that are otherwise way too big to build until we validate the idea.

And because PostIts fall down, get lost easily and cannot be logged, we ended up back on Pivotal. It was almost instinctual. So here is how we use Pivotal Tracker to plan and manage Heart. Papers. Border. now:

YES I work on 3 screens and NO its not enough
YES! I work on 3 screens and NO! it’s not enough

Here are OUR rules and routines:

  • When we work on Heart. Papers. Border., Pivotal is always open
  • We make sure we Deliver the stories as soon as we finish them – so we know what can be tested
  • When we get noteworthy ideas, we add them immediately in the Icebox
  • We constantly review and update (groom) both the backlog and the icebox
  • We have a Working Build at the end of the week, and a bunch of work that has to be Accepted or Rejected. We already know we will Accept most if not all of the stories, but we keep the list anyhow as a quest list for how to play the game together (or with friends) on Friday. You can never really have enough testing.

Here is what we cheat with:

  • We don’t quite write gamedev tasks, but we don’t write user stories either. We can afford the cheat, because its just the 2 of us some 2 meters apart, and we have been working together for over a decade.
  • We did not add ALL the stories we need to have for the prototype. We have a wiki where we do that, and we add tasks progressively so Pivotal can do a good job to keep us on track without overwhelming us
  • We rarely track writing blog posts or keeping our friends updated on Twitter, Facebook, Reddit or Pinterest. Those are things we do anyhow out of joy, but if we would need any reminders, we would add a few chores.

But enough with Practice, lets do some theory!

Why Pivotal Tracker

Pivotal Tracker is “an agile project management tool that enables real time collaboration around a shared, prioritised backlog.” There are Many, Many, MANY tools out there, very elegant and powerful, but I use Pivotal tracker for the following reasons.

  • it is Online. I can be sure that no matter how many people are in my team and no matter where they are, we see and work on the same backlog.
  • it is Simple Enough. You can only have Features, Releases, Chores or Bugs, and the amount of fields to fill in for each of them is minimal and extendable to your hearts content.
  • you can really make Estimations work for you. I always use a 1, 2, 3 point scale because we don’t really need more than some constant way to track our progress, since we have a decade of experience of working together. For new teams you can really focus on learning how to work with each other instead of learning how to use a management methodology or a software
  • you can drag & drop to plan and prioritise
  • you can make your Releases BLOOD RED really early if you are in danger of not finishing on time. I really appreciate a red line that tells me early if I am in trouble

The Radiography of a fresh Pivotal project

You can create a Pivotal Tracker account here and use the software for free as long as you want, but only for 2 private projects with 2 collaborators each. This means Pivotal is Perfect for teams of 3 people and problematic for bigger teams. As a general project management rule of thumb, it is pretty crucial to have ALL your team on the same planning tool, otherwise you get communication chaos.

Here is how your very first Pivotal project looks like, fresh after creation

Much grey very wow! Fill me up, Scotty! <3
Much grey very wow! Fill me up, Scotty! <3

Notice that the upper part of the UI is dedicated to general tools like your Project, your STORIES (more on that later), Search, What’s new, Help and your account.

NOTE that since Pivotal is Online and it IS a software as a service, it gets updated A Lot, which is both good and bad. The bad part is that if I would write this post a month from now, the above screenshot will probably differ. This can be really confusing sometimes. 

To your left, you have a sort of a menu bar that you can expand or collapse, so you can de-clutter your space. I never collapse it, because I always add stories but that is the bane of every SCRUM master (and I have all the planning, management, vision holding roles for Heart. Papers. Border. – definitely NOT recommended for bigger, younger teams)

The left menu bar is important because not only does it allow you to Add Stories and toggle Working Panels, but it also grants you quick access to your Velocity, Team, Project Colour and Story Density. Waddup with Those?!

  • Velocity is the amount of Points your team can do in a Sprint. It’s the most important number used in calculating whether or not you will hit a milestone and it is always a median between the 3 latest sprints (or however you decide to set it). But the left side toolbar allows you to Override it! This is not permanent but the magic of it is that it lets you predict how your situation would be at a higher speed (say if you get some help, or just work more) or at a slower pace (say someone in your team gets sick)
  • Team is the stuff you click the moment after you made your fresh new Pivotal project. This allows you to invite all you team members, and you need them if you want to assign them work!
  • Project Colour is something you can ignore, unless you have a gazillion projects in your pipeline and hence in your Pivotal account.
  • Story Density just increases the way your stories are displayed but it is awesome especially for when you do Build Reviews (that is why you have the Projector option). You see, SCRUM means you are supposed to look over Pivotal often with your team, while playing your fresh build and then updating your stories for everyone to see and approve.
I wonder when can we finish if we do NOTHING?!
I wonder when can we finish if we do NOTHING?!

Next, you get:

Add Story – this is your main tool to add your User Stories, defining everything your player should do. As I detailed before, a good collection of user stories should look like a design document. But this tool lets you add more than that. Specifically:

  • Feature lets you add a user story that can be estimated in points (actually takes time to do).
  • Bug is a malfunction that needs fixing and does not need any estimations (because you didn’t intent to Code A Bug, RIGHT?!)
  • Chore is something that you need to do, a reminder, kinda like washing the dishes. Its easy and simple and repetitive, but needs no estimations.
  • Release allows you to add a calendar that that you can then drag and drop as a deadline for all the user stories listed above. This is a very useful tool because it literally turns red if Pivotal realises you will not finish all your stories in time for that calendar date.


All the other menus under Add Story are actually panels of information that you can toggle on or off in the main screen. They allow you to quickly access whatever you want and also de-clutter your space during work mode. While My Work, Current/ BacklogDone and Project History are pretty self explanatory, I want to talk a little bit about the Icebox, Epics and Labels.

  • The Icebox is the place where all stories end up first. This is truly an elegant design that forces you to consider whether your story is truly worthy of attention now, or is it just a nice to have that you should get to whenever you deal with the urgent things. The icebox keeps your ideas “on ice” until you manually drag and drop them in the Backlog. Or until you Start them. Theoretically, your Icebox can easily act as your idea collector, but it is always good to groom it periodically to avoid clutter.
  • Labels are what they are called, a quick way to categorise and sort your user stories. They act like tags and their only job is to help you quickly sort through a large quantity of work. Labels can be applied to everything, even to Icebox stories. A lot of devs ask me what is the best practice for labels, and well, it’s simple: there is no best practice. You can use labels such as “code” or “art” or “menus” if you notice in your daily work that you frequently need to see all art heavy tasks or many all the tasks related to the menus. You can also use more descriptive labels such as “main feature 1” – it is always up to you and what you need! You can also assign multiple labels to a single story and – it is not a mistake that I wrote about Labels before Epics
  • Because Epics are Super Labels. They are labels that get their very own progress bar, where you can easily see how many stories you have under that Epic and their progress, at one glance! Epics are yet another topic where a lot of gamedevs seek best practices. But again, it is up to you to use Epics for what you need. What is it you need to track? I have seen people using important events as Epics, and making sure everything for that particular show is done in time. I have seen developers using epics for Assets, to make sure the big asset list gets done. Just think what you need tracking, and how important it is for you to know that those stories are delivered!



Questions so far?

I will leave room for Part “Another One” if this one’s useful! We should still talk about Analytics, Grooming, and the power of actually knowing your working speed! If you want Another Part, I’ll write it… but Only if you check our the Heart. Papers. Border. website, subscribe to our mailing list and follow the Heart. Papers. Border.  Facebook page  / Shameless Marketing Plug.

No seriously. We appreciate the help immensely, but only if our game has any value to you <3 

Back to Top
%d bloggers like this: