We're introduced new features in Pivotal Tracker to help with account management. Accounts tend to stay out of the way for most people, but they can be essential for larger companies, especially consulting companies like ours. They allow users to separate their personal, open source, and company projects, for example, and to share administrative abilities and permissions for related groups of projects with other users.

Continue reading for details about these new features.

We will be performing a maintenance update to Pivotal Tracker tonight (Friday, Sep 17) starting at 8:30pm PDT. Anticipated downtime is under one hour.

This update will include a few performance improvements, bug fixes, and some new account management features.

Due to last night's brief unplanned outage, related to a necessary database upgrade, we are moving tonight's scheduled maintenance to this Friday night (Sep 10). The maintenance will begin at 8pm PDT, and we anticipate approximately one hour of downtime.

We're excited to add a new entry to the 3rd party tools directory: Aragorn, the first Pivotal Tracker client for the iPad.

The first version of Aragorn supports read only views of your projects and stories within them. Thanks to @elight for writing the app!

Our managed hosting provider experienced an extended network outage today, which affected a number of applications including Pivotal Tracker.

The outage was caused by a failure of a primary network load balancer. Network engineers have replaced the load balancer, and are in the process of investigating why traffic did not fail over to a secondary load balancer as expected. They will be performing a fail over test early this morning, from 1am PDT to 3am PDT, during which time some Tracker users may experience increased latency.

We appreciate everyone who notified us about this outage, and apologize for the inconvenience of not being able to access your projects this morning.

Three interesting new user-contributed Pivotal Tracker tools have been added to the growing 3rd party tools list this week:

Pivotal Tracker Story Board

From vizio360, this is a Google Chrome extension that allows you to visualize your current iteration as a card wall, with columns for each story state.

whereuat

Adds a slide out panel to your rails app that directs clients to test stories that have been marked as 'delivered' in Pivotal Tracker. Thanks to PLUS2 for this one.

Pivotal Attribution

Text-based tool for tracking story completion per-user on Pivotal Tracker, from Joshua Szmajda.

We're looking forward to trying these on some of our own projects at Pivotal. Thanks to everyone who's shared their work with the Tracker user community so far, and let us know if you've written something new that you'd like to share.

We received notification from our hosting service provider Engine Yard, about scheduled data center maintenance tonight (Tuesday Aug 3) starting at 11pm PDT, lasting approximately one hour.

During this maintenance, Engine Yard's infrastructure partner Terremark will be updating the configuration of spanning tree on network switches, to be able to hot-add resources in the future. A direct outcome of the maintenance will be increased network stability.

During this maintenance window, Tracker may experience high latency or downtime for 5-10 minutes at a time. There may be a number of short latency/downtime periods during the window.

Local deal pioneer, and our client Groupon has just launched deal personalization, allowing users to receive deals that are more relevant based on zip code and personal preferences. This is great for all the fans of Groupon out there, as it gives them more interesting deals to choose from, and it allows Groupon to distribute more deals in each city it serves.

We're excited to have gotten a chance to help with this feature, and look forward to seeing how this reshapes the daily deal landscape!

There appears to have been a data center outage early morning, affecting a number of applications including Pivotal Tracker. This has caused connectivity problems for users in some locations, and it appears to still be persisting for some.

We're working with our hosting provider to get this resolved as soon as possible, this is our top priority.

This is the second data center outage this week. At the moment, we do not have enough information to know whether the outages are related.

Also, we have received reports that Tracker has been unreachable from certain parts of the world (including China) since the migration to a new data center last week. We've filed a request with Engine Yard to investigate, and hope to have this resolved soon.

Our apologies for the inconvenience these outages have caused. We'll post more information here as we receive it. You can also follow @pivotaltracker on Twitter for updates.

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).