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

Pivotal Tracker is moving to a new private cloud hosting environment at Engine Yard this Thursday, July 22, starting at 8pm PDT.

Planned downtime is approximately one hour, but because we're changing IP addresses of the Tracker servers, it may take longer for DNS changes to full propagate.

If you've opened your firewall to a specific IP address for Tracker integrations, you'll need to make changes. We'll post the new address of the integrations server after the move, you can also 'ping api.pivotaltracker.com' to resolve it.

Apologies for the inconvenience, we're hoping for noticeable performance improvements in the new environment.

With Github's help, we've added Pivotal Tracker to the list of Github's built in service hooks, making it easier to tie commits to Tracker stories.

To set it up, go to the Repository Administration section of your Githup repo, click on Service Hooks on the left, and choose PivotalTracker from the list. Enter your API token, and you should be good to go.

More on Tracker commit hooks on the API help page.

We're forming a Tracker User Group in the windy city, and the first meetup is scheduled for Jul 22, at the Hashrocket Chicago office.

I'll be there to talk about the concepts and history behind Tracker, our experience with it, and will give a demo to those that are interested. It's a great place to give feedback and ask lots of questions.

Space is limited, so RSVP soon.

We're forming a Tracker User Group in the windy city, and the first meetup is scheduled for Jul 28, at the Hashrocket Chicago office.

I'll be there to talk about the concepts and history behind Tracker, our experience with it, and will give a demo to those that are interested. It's a great place to give feedback and ask lots of questions.

Space is limited, so RSVP soon.

For the next month or so, we will be rolling out a series of changes to various parts of the Tracker server architecture, including moving to a Memcached distributed cache for certain requests, cookie based sessions, switching from Mongrel to Passenger, splitting the very large history table, etc.

We're doing this to improve performance, and eliminate potential scaling issues as our traffic grows. To reduce risk, we'll introduce these changes in separate updates, once a week.

These updates will occur on Wednesdays at 7:30pm PDT (including tonight), and last under an hour each. If there are any long running migrations needed, we'll plan them for weekends, or handle them incrementally, to avoid any extended down times.

We understand that these week night outages are inconvenient to many of you, especially in Asia. We apologize in advance, and will try and keep the updates as brief as possible.

The next scheduled meeting of the New York Tracker Users Group (NY.TUG) will be on July 1, at the Pivotal Labs New York office.

We will be giving an overview of the idea behind Pivotal Tracker and the common features. Based on time and interest, we'll also go into more detail about advanced features, upcoming features, and the philosophy behind Tracker.

Beverages and light snacks will be provided.

Please RSPV soon, as space is limited.

If you're looking for custom reporting and analytics for your projects, Easy Insight just added integration for Pivotal Tracker.

More details about how it works on the Easy Insight site.

We're big fans of the RubyMine Rails IDE, and are excited to see that JetBrains has added Pivotal Tracker integration in the latest EAP update.

The integration lets you easily pick a Tracker story from within RubyMine and create a task out of it. RubyMine tasks let you organize your work into different contexts. You can switch between tasks, and create source control changes based on them.

To use it, you'll need a Tracker API token. Go to your My Profile page to get that.

Next, in RubyMine, go to Settings, and add a Pivotal Tracker task server (under Tasks/Servers). Use http://www.pivotaltracker.com for the URL, and enter your API token and Tracker project ID.

Note: This version of RubyMine sometimes hangs when trying to add a task server through the settings UI. As a workaround, you can edit the workspace.xml file, located in the .idea directory under your Rails root. Add the following under the element:

<servers>
  <PivotalTracker shared="false" url="http://www.pivotaltracker.com">
    <option name="APIKey" value="YOUR_API_TOKEN" />
    <password />
    <option name="projectId" value="YOUR_PROJECT_ID" />
    <option name="useHttpAuthentication" value="false" />
    <option name="useProxy" value="false" />
    <username />
  </PivotalTracker>
</servers>

Once the task server is configured, you can use the Switch to Task dropdown in the RubyMine tool bar to add a new task based on story in your Tracker project, or change between existing tasks.

You can optionally create a source control change based on the task, allowing you to preserve the story context all the way through to the commit.

If you've using Tracker's post commit hook to automatically link commits to your stories, you can reformat the change description to match what Tracker expects (e.g. [completes #123456]) before you commit the change.

A common feature request from teams that have multiple projects on the go in Pivotal Tracker is the ability to move stories between projects. We've just added that feature.

To move a story, or a group of stories, select them first, using the selection check boxes to the right of story titles:

Then, select the 'Move to Project...' option in the Actions drop-down, and choose the project you'd like the story or stories moved to:

You should see a message that the stories were moved, and there should a history entry for the move as well, both in the source and destination project. Moved stories retain comments, tasks, attachments, as well as their own history of actions.

It's also now possible to move stories to a project via the API. Simply do a story update, with the target project's ID in the story's element. More on that on the API help page.

Starting Jun 30, the Twitter API will no longer allow 3rd party applications (such as Tracker) to connect using your Twitter username and password. Instead, applications will be required to use OAuth, an authentication protocol that allows users to approve a 3rd party application to act on their behalf without sharing their username/password.

Pivotal Tracker now uses OAuth for project Twitter notifications. When you enable this feature for your project (see the integrations help page for more on that), you'll be asked to sign in to Twitter (on the Twitter site), and give the Pivotal Tracker application permission to access your Twitter account.

If you have enabled Twitter notifications for your project(s) prior to this release, the stored credentials are in the username/password format. You'll need to remove these old credentials, by clicking the 'Remove Twitter Credentials' button. After you've done that, click the 'Sign In With Twitter' button to re-enable the Twitter notifications using the new, more secure OAuth way.

More information on Twitter and OAuth can be found here.

We'll be making some DNS changes that affect Pivotal Tracker this Saturday, May 29, at 10:00am PDT. We expect a fairly short outage, but for some users, Tracker may be unavailable for up to 6 hours.

Pivotal Labs has been at the forefront of agile development since it's early days. We've taken what we've learned by applying agile concepts on a countless number of real world projects, and honed these skills into a very effective way to build software. Along the way, we also built a great project management and collaboration tool - Pivotal Tracker.

Not only does Tracker serve as a critical component of our own development process, it's also relied on by thousands of teams out there in the world, from open source developers, to fast growing startups, and high profile, established companies.

It's a great app, yet we have lots of ideas for how we'd like to improve it. Want to help us? If you're a Ruby on Rails developer, enthusiastic about agile development, and want to help us to take Tracker to the next level, read on.

We're currently looking for developers in the Denver/Boulder, Colorado area. Familiarity with Ruby on Rails is important, as are strong Javascript, CSS, and overall web UI skills. At Pivotal Labs, we pair and test drive 100% of the time, so any experience with pair-programming and/or test driven development would be a huge plus. We're also big on aggressive refactoring, so be ready to roll up your sleeves.

If you're interested in working with us, please send your current resume to tracker-jobs@pivotallabs.com, and tell us a little about yourself. Principals only, please.