PivotalTracker Best Practices [closed]

Question

(For those who haven't heard of it, Pivotal Tracker "is a simple, story-based project planning tool that allows teams to collaborate and instantly react to real-world changes. It's based on agile software development methods, but it can be used on a variety of types of projects.")

We're about to ramp up with a workflow based around this outline by Rein Henrichs and were curious for opinions on how to break down product components into projects.

We've experimented some with tagging but it seems that if there are a lot of components to a system (a photo viewer, a video viewer, a news feed, a notification service) a single project can get pretty crowded.

At the same time, for versioning etc, it seems it might make more sense to have it all in one project regardless of the clutter.

Any thoughts? Opinions? Comments? Thanks.

Answer 1

Remember that Tracker is a story-based planning tool, not a task-based planning tool. From the standpoint of the customer, it doesn't matter if the story impacts the photo viewer, the notification service or both. The customer has some stories (high-level requirements) they would like to have implemented, they have estimates about the cost of the stories, and they have the ability to prioritize the stories. Breaking things into components is a task-level problem.

More importantly, breaking stories for the same product into multiple tracker projects would make it difficult for the customer to communicate how they prioritize the stories, or get a good estimate as to when stories might be completed.

We use Tracker to track our stories, and we have our own board were we track tasks. I personally think it would be useful to track both stories and tasks in Tracker, but the tool doesn't support it.

Answer 2

It is probably best to have a single project to contain all your stories. That way, you have a single place for the entire team to see what is going on with the project and what the current priority items are. If you have your stories broken down enough that they can be the features in Rein's process, you're in great shape! At the end of the day, having a prioritized list of features is all any development team truly needs. Use the tags in Tracker for filtering. They work well. In my opinion, breaking a single product down into multiple, dependent projects actually obscures information and makes it harder to get visibility on the true state of the project.