Brief discussion on how to structure Scrum TFS projects

Topics: Project Management Forum, User Forum
Sep 11, 2009 at 2:35 PM

We are looking to introduce TFS and Scrum into our organisation to give us a slightly more structured approach to managing our product development process.  I'm happy with Scrum as an approach, but get hung up on how we structure the TFS team projects.  We are only a relatively small organisation, we have a single dev team of 4 people, augmented by a tester and a trainer for a sprint making a team of 6 (including the Scrum master).  We have four key products that we develop and have independent product owners each maintaining a backlog for their own product.

I think that I'd like to have a single team project which I use on an ongoing basis so that I don't lose track over time of historical information about delivery.  Having a single team project means that I can have one central source control history and work items that are available for historical reporting, but it does mean that the projects may become unwieldy so I can see the benefit of having a team project for a product release or even, possibly, a single product increment.  I could also see the benefit of having a Team Project per product to manage Product Backlog and specifications etc, and then transferring work items and specification documents to the relevant place for a specific release or iteration after the sprint planning meeting.

What I would like to know is other peoples experience, what is a good balance to strike between compartmentalising the projects so that the development team is focussed on the current increment or release, and making the team projects easy to manage?

Any feedback gratefully received.

 

Nov 24, 2009 at 7:52 PM

We use one TFS project per product that we ship. Each product will (hopefully!) have multiple releases over the course of its lifetime. We set things up thusly:

  1. Source control - Trunk (or Main) represents code which is currently shipping; development on new product releases is done in branches (with bugfixes for the shipped version being done in trunk - these changes can then be forward integrated into the development branches at regular intervals). When a release is ready to be shipped, the branch gets merged back into trunk, and we are done. This exploits the power of any source control system, being able to manage concurrent changes to the code. Developers only need to check out the branch that they are working on, without having to worry about trampling over code that is currently in production. If a release is killed, the branch can be abandoned or blown away as necessary, while trunk remains unharmed
  2. Areas & Iterations - Areas are used to define particular units of functionality - the main consumer website, the backend administration system, externallly exposed web services etc. Iterations are then used to manage a product release, breaking up the release into one or more sprints; TFS is happy to allow as many concurrent product releases as you care to enter.

Frmo my experience, having multiple TFS projects to manage a single product causes too many mangement headaches, especially when it comes to reporting - the real beauty of TFS is its ability to report based on the data from all the areas of a project, but generally the reporting is limited to per-project. I don't doubt you could create some cross-project reporting, but being able to track the history of a product through all its releases using out-of-the-box reports is almost worth the price of admission to the world of TFS alone.