Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

  • Blog Navigation
One team, one Tracker project

I often hear questions from Pivotal Tracker users about how to organize teams and projects. We also see many requests for features that would make it easier to see stories from across multiple projects.

Tracker is designed for full immersion in one project at a given time. This stems from how we work at Pivotal Labs.

We organize teams such that a single team (and the people on that team) have a single backlog (and Tracker project). This means that within a team, there are no conflicts in terms of priorities, there is less context switching, and the team is completely focused. It leads to more consistency from iteration to iteration and therefore a steadier velocity, which allows you to have a more accurate insight into how long the rest of the backlog (or a release) might take to complete.

We also make it so that anyone on a given team can grab the next available story from the top of the backlog (or the current iteration). This implies few or no specialists (there is no back-end guy), and is generally referred to as collective ownership. It increases overall efficiency by allowing the team to dynamically re-balance, and minimizes reliance on any individual person (which among other things, leads to more relaxing vacations for developers).

The project’s customer (or product manager) focuses on prioritizing stories in the backlog, and the development team is collectively responsible for delivering software based on the backlog.

We use labels to tie related stories together within a project. These can represent a major feature, specific end customer, etc. Labels can help answer questions like, how much work is left in this large feature?

A single backlog for the entire team does put more work on the plate of the owner of the backlog (customer / product manager), as he or she has to constantly make potentially difficult prioritization decisions, but, thinking hard about priorities is a good thing, and it allows the development team to focus on getting more work done. That ultimately makes everyone happier.

Also, there are people in certain roles (for example executives and designers), that given their nature, tend to be involved with multiple projects at once. Tracker could certainly use some features to help these roles, and we’re thinking about these, but overall, it’s more oriented towards enabling the immersed team.

A single team/project can get large enough to the point where it becomes challenging to manage a single backlog. For us, this point is generally reached with 5 to 6 pairs of developers (or 10 – 12 people). Assuming that more developers can actually add value to the overall project (this is not always the case), it’s probably worth considering splitting the team into multiple smaller teams, each with their own single backlog.

To avoid knowledge and cultural silos with multiple teams, we find it helpful to rotate a few people around teams every iteration. It’s important to maintain consistency (and therefore a steady velocity), so you don’t want to shift too many people around too often – usually rotating just 1 person (on each team) each iteration is enough, assuming you’re pairing and switching pairs within each team often.

In a multi-team (and Tracker project) environment, the product/project manager acts as a load balancer, and allocates work across the multiple teams/backlogs by considering velocity, dependencies, etc. This is typically a full time job. Tracker doesn’t have much out of the box to help with this, but we’re thinking about this as well, although it may be that some of this kind of work is better done in a spreadsheet, or other, more traditional project management tools. (As a side note, we did recently add the ability to move stories between Tracker projects, making things a tiny bit easier for people who manage multiple teams/projects).

I’d love to hear your thoughts on any of this, including suggestions for how to organize large projects and multiple teams (and how Tracker can help with that).

  1. Adam Lwoe says:

    All sounds very similar to how we work with Pivotal Tracker and projects at Hashrocket. +1

  2. PJ says:

    I think this is a wonderful post that users old and new to Pivotal Tracker should read, if not immediately then definitely eventually; as they’ll most likely ask these questions as situations inevitably arise from dealing with multiple projects and teams.

  3. James Z says:

    Hi Dan, good post. One solution that you can retrofit on top of your existing design is to provide the ability to “Create Teams”, the view for a Team would essentially consist of aggregate of multiple projects, a project can only be allocated to one team. While in team view, you can see the whole backlog and if you wish you can always drill down to the project view. The velocity for the team in this case would be more meaningful than the velocity for the project itself. But the velocity of each project can be used as a relative measure against the team velocity (e.g. to figure out % time spent on a given project). Prioritisation of stories within a particular project can be done in the project view, but of course you should be able to do this in the team view as well. One potentially problematic issue though is determining how to display the stories from different projects in the team view when a project is first added to that team, e.g. how do you determine which story from which project should be display first, perhaps this can be done in a round-robin way or alternatively when a project is first added, the user is forced to prioritise the stories against the other stories from other projects. Just an idea.


  4. @James Z: That is an incredible idea. I love it. Being able to figure out for a team the relative time spent on different projects once they are past the 5-6 pair threshold would be very valuable.

  5. Chris says:

    Great post – you should have a link on the main website to “example of how Tracker can be used in an organisation” – and as you say, if others write in with different descriptions, you could show some contrasts.

  6. Simon Chiang says:

    I like what @James Z proposes. Where I work we need that kind of functionality to integrate Tracker into our workflow. In fact, the inability to manage multiple projects within a team is one of the main reasons why we haven’t moved to Tracker.

  7. I used to have very similar thoughts. However, there are many situations when 1 team != 1 project. There are large products where several teams working on a single backlog and it is hard to split it to several separate teams. Prioritizes are cross-project in this case anyway, since full product provides a value, not just one project with 1 team.

    In general there is a Convey’s law “…organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations”

    That was true for TargetProcess, that is true for PivotalTracker. Last year we added multiple projects support into the product and many customers are happy with the addition.

    However if you target small teams, PivotalTracker is better than TargetProcess on my opinion.

Post a Comment

Your Information (Name required. Email address will not be displayed with comment.)

* Copy This Password *

* Type Or Paste Password Here *

Share This