We'll respond shortly.
A frequent feature request for Pivotal Tracker is support for parallel tracks of development for multiple pairs of developers (you are pair programming, right?) It’s true that Tracker does not fully support parallel tracks within the same Project, but you can get most of the way there by doing what we do on many Pivotal Labs projects: use labels to identify multiple tracks of development. With labels, you can easily visualize and manage parallel development tracks while keeping your team’s work in one Pivotal Tracker Project.
It is a common scenario to have two pairs working on two unrelated feature sets. For example, your application will allow users to shop for and purchase products, and also have many administrative/back-end features. The team has identified that there are too many dependencies to have both pairs working on the shopping portion: one pair can’t work on credit card refunds if the other is in the middle of implementing credit card purchases. Thus, the team decided that one pair will focus on the shopping features while other pair works on important admin tools.
“If it’s the most important story, put it at the top of the backlog” has long been one of our go-to suggestions. This is more difficult with parallel-track teams, as you have multiple number-one priorities. Labels to the rescue! Notice that we’ve labeled all of the shopping-related stories with a shopping label, and the administrative stories with an admin label:
Now click on the shopping label. Notice that we grow a new Search Results column for stories labeled shopping which has several interesting properties:
After clicking the shopping label, pin it by clicking the little push-pin icon in the upper-right corner of the search results column. Now you can perform another search, or click another label, without losing your shopping column!
Go ahead and click the admin label after pinning the shopping label.
Now you have easy to visualize tracks of stories, priorities, and estimations, side-by-side.
The label trick is a very handy tool for managing parallel tracks of development on your project, but it isn’t perfect. Ideally, if the shopping features are the most important for your project, everyone possible should be working on them. Implications of parallel development tracks in Pivotal Tracker include:
Harder iteration planning: Tracker fills your iterations with the highest priority stories, but with parallel tracks you have multiple high priorities. In our example, Tracker fills the top of your backlog with shopping stories first and admin stories afterwards. The burden is on the team to either interweave the two tracks in each iteration, or group all of the similar stories together and “just know” that your admin stories are not actually weeks away but are indeed being worked on now.
Predictability: Depending on how you use Release markers, some charts, such as the Release burn-down chart, become less useful. For example, some teams might create Release markers for shopping and admin as a way of grouping these stories together, but the burn-downs will be less accurate if teams are working on both sets of stories.
Slightly harder to manage: One thing you’re sure to notice is that you cannot drag-and-drop within the search results panels, which means that you cannot re-prioritized the stories within the shopping and admin columns, though you can drag items from search results into the backlog. Also, if you add or remove labels, or re-prioritize, you will have to perform the search again refresh the column.
Anti-pattern?: Some schools of thought, such as followers of kanban, might consider parallel tracks of development an Anti-pattern. Definitely weight the impact of fracturing your development efforts.
UPDATE: fixed wonky images.