Generally speaking, a decent rule of thumb to follow when thinking about team projects is that team projects “are bigger than you think”. Another rule of thumb to consider when deciding your approach is to look at the effect of a typical requirement on your software development project; if this requirement, for example, affects several applications or tiers (like front end, middleware and backend) then all these application should be grouped under the same team project.

Each scenario is different and every organization is different but the following three approaches are common approaches that might fit your needs:

• Application
• Release
• Team

Stuart Miles

Team Project per Application

When business requirements (both functional and non-functional) are usually considered and build by the entire application and a software development team is working on them then the Team Project per Application is a common approach. Applications usually have long lifecycles, starting from inception, moving to actual development phase, transitioning to support mode and going through end-of-life phase. A typical mistake made by single teams that are responsible for several connected/related application is to split and create a team project for each application. This split introduces difficulties when managing and sorting priorities across those projects. The Team Project per Application model generally works best on large applications that have dedicated team or teams working on the application throughout the application lifecycle.

Team Project per Release

The Team Project per release is suited for very large projects with very large teams spanning long timelines. It works very well for Independent Software Vendors working on actual software products; whereas consulting teams or internal software development teams working on line-of-business software projects tend to not fit into this model. Having said that, in the early stages of the software product (when it has not released yet to the public or sales are still low) it often works best to actually start with the Team Project per Application model and in time, as the product increases in scope or traction, transition to the Team Project per Release approach.

Team Project per Team

Another approach that works well in situations where the software development team structure and size tends to be consistent over considerable lengths of time the Team Project per Team approach is very often the most suitable model. If your software development team finds itself working often on more than application at a time, or subsets of this team work together over time then consider the Team Project per Team model.