Reno, NV    +1 (800)0 621-0871

Go back

Project Management

Organizing for Agility and Success Part 2: Advanced Tracker Techniques

  |  June 10, 2015
Image courtesy of

Image courtesy of

In Part 1 of this series, I discussed basic techniques for organizing an Agile backlog using Pivotal Tracker. These techniques are best applied along with a set of agile heuristics which I describe in ÆLOGICA Flavored Agile.

When your project is larger and more complex — say between one hundred and one thousand story points or more, it will have different moving parts whose progress should be individually tracked and prioritized. Even with proper use of labels, projects with several epics and different phases or releases for delivery quickly become difficult to manage without applying some technique.

Here are a few techniques I use to tame these beasts:

  1. Releases within Epics
  2. Releases across Epics
  3. Multi-project Workspaces
  4. Dashboard integrations

First of all, you want to look at your Epics and make sure you have chosen a handful of good epics. Make sure every story belongs to an epic. Epics should be named after high-level user activities. Examples for a typical SaaS application would include “managing content”, “registration (on boarding)”, “recurring billing”, “customer support”, “managing my account”, etc.

Releases within Epics

We use releases as anchors in the Backlog. Items before or above the release go “in” the release and are required to be accepted before the release itself can be accepted. Items that are below the release, are not considered to be part of the release.

Releases can be tagged and scoped to Epics and then arranged in relative priority in the backlog. I refer to this as “Releases within Epics.”

To utilize this technique place a Release in each Epic. If you are planning a launch, then for each Epic, place a launch Release named “<epic> ready for launch” or “<epic> 1.0 release.” Move these releases from the Icebox to Backlog. Without worrying about what is part of each of those releases, arrange them according to priority.

Then one at a time, open each epic and move the stories above or below the Release according to whether it should be part of the release or not.

Once you complete this for each Epic, when you open or look at your backlog, you will see a nicely ordered progression of value delivery broken into digestible chunks. Once you have the track record and estimation complete, when someone asks, “When will XYZ be ready?” you can look at where the release falls in the backlog had have a pretty good idea.

Releases are just markers. In Tracker, the icon used is a little flag. Think of planting a flag in the backlog with the marker. Then stories are moved ahead or behind the flag.

Releases across Epics

Sometimes you want to create a release for the overall release. When all components are ready for a launch. This helps you see when “everything” will be done, not just each individual component.

For this, create a release entitled “Launch” or “1.0 Release” and then tag it with every epic label that is pertinent to that release. Drag it to the end of the backlog. Within each epic, it should appear as the first item after the epic specific release, before any stories that are not part of the release.

Multi-Project Workspaces

Sometimes, even with well-conceived epics and release properly organized, things still get out of hand. Teams have trouble seeing what is going on or have to fight through clutter (items unrelated to them) to see what to do next.

For more complex projects like this we can utilize a Multi-Project Workspace. Why would you want to do this? Isn’t it better to have everything integrated into one? Yes and no. Even if your team is small, if there is a clear separation of concerns where one developer or group will only touch stories from certain epics while others will work on different epics, dividing into more than one project might be helpful.

It is possible that the project would be less confusing for them if they each only saw their own stuff. You will lose your one single “velocity” number but in reality, those teams each have their own velocity and since they will not be picking each other’s stories their labor is not fungible. Therefore their “average” velocity is not that meaningful. Pulling these projects apart will actually give you more realistic and meaningful velocity numbers.

The way to do this is to create a Multi-Project Workspace. Here’s how:


  • Create the Workspace.


Create a project for each group of Epics. If you have two or three major fronts of development with different individuals focused on each, then you should probably have two or three teams and two or three Projects. Add each of these projects to the Multi-Project Workspace.


  • Duplicate the epics.


Create new epics in the new projects for the epics that you want to move. Make sure they have the same labels as they do in the original project. Eventually Tracker may allow you to move Epics between projects but right now it does not so you must tediously duplicate them.


  • Move the Stories and Releases.


Use the select functionality to drag multiple stories from the epic on the old project to the new project. First select the items you will drag to the Backlog and move them. Then select the items that will go to the Icebox and move them to the Icebox on the new project.Use this opportunity to prune the Backlog and Icebox on the old project. Remove junk.

Now observe your handiwork.

What was a confusing jumble of stuff has been reduced to two or three separate, smaller concerns. The project teams will appreciate the clarity and will have better visibility into their own progress. When might you want to keep everything together?

If your team numbers 6 or fewer developers and if the team really is fungible — any person or pair can work on any part of the system — you might want to keep it all together. If epics are short-lived and do not span phases or releases, you might want to keep it all together. If your project is not that complex and only has 3 or 4 epics at time, you might want to keep it all in one Project.

Dashboard Integrations

I have recently begun to work with a fantastic tool built on top of Tracker — it is something I have wanted for a long time — a Dashboard. The one I am using is from

While it offers stock dashboards for Scrum and Kanban style Agile, I have found it more useful so far to configure my own. I have two purposes for a dashboard. First, I want to use it to better understand how we are progressing across multiple projects since I have configured a Multi-project Workspace. Second, I want to display my dashboard on the information radiator (a 50″ HDTV) in the common area of our office so that our team and other people in our organization can be more conscious of the team’s progress.

Office dashboard displayed in the common area of ÆLOGICA’s office works very well in combination with Multi-project workspaces. The widgets can be configured to filter their input data on labels across multiple active projects. They don’t even have to be in the same workspace!

If you need to get a heads-up overview of where you are with respect to completion on high-level value-delivery to the business, a completion widget can measure a percentage of completion across a set of labels. For example, let us say the business owner has a strategic goal to establish a new income stream from a new product. Everything relating to making money with the new product might go in a completion widget “Making Money from X.” This helps to keep individual contributors from getting lost in the weeds and to see how their effort connects with the priorities of the business.

By applying the techniques described here and in Organizing for Agility and Success Part 1, as well as my heuristics for Agile development as practiced here at ÆLOGICA, you can tame even very large and complex projects with thousands of story points.