views:

359

answers:

2

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

+1  A: 

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.

kstewart
+1  A: 

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.

NamshubWriter
Interesting. So stories would have multiple tasks, and a team member could determine what tasks are needed to fulfill the story.In light of your answer am adding a comment to the question regarding unit tests. Lmk your thoughts.
Matt Gardner
This is a bit of a digression from the question, but since you asked:Stories should have acceptance tests (tests to verify the user story has been correctly implemented). Ideally, almost all code should have unit tests.The important take-away is that having one prioritized story list that is shared between the customer and the developers has a number of advantages.Some teams find it useful to have a second prioritized list of tasks for the developers. It's unclear from the question whether multiple Tracker projects were being considered for use in tracking tasks or tracking stories.
NamshubWriter
@NamshubWriter: Did you know you can enable tasks against stories now within Pivotal?
jkp