How Microsoft/DevDiv uses TFS – Chapter 2 (Feature Crews)

One of the issues that Microsoft has to deal with on a very large scale is that while they are managing 1200 individual features, all of this works on a single code base. With all that activity going on, how do you maintain the quality of the code base, while allowing individual teams to focus on their features.

Our answer is feature crews. Its a model we adapted from the Microsoft Office team. It looks something like this:


When a feature crew (a team of people) is assigned to work on a feature, the lifecycle looks like this:

  1. The feature crew creates a branch of the main source branch, to provide an isolated environment to work on their feature. They are isolated from any churn going on in the source branch, and they isolate everyone else from their work
  2. As they work on the feature, there are two checkpoints. Checkpoints are when they present to management, to ensure management is in the loop of what is being done, and allows management to provide feedback on direction. Checkpoint #1 is about design. Here the feature crew presents how they plan to solve the problem.
  3. Checkpoint #2 is about demoing the functionality. Here the feature crew presents what they actually did to solve the problem.
  4. Once they've completed the feature, the feature crew integrates any changes that have taken place in the main source branch into their branch.
  5. Before they check their changes back into the main source branch, all feature crews needed to meet a set of quality gates. Quality gates included things like "No performance regressions" and "70% code coverage through automated testing".
  6. Once the feature crew had verified they had met the quality gates, they can then check their changes into the main source branch. The quality gates protected the main source branch, ensuring it was always in a near-releasable state.

NOTE: The goal was that a feature crew could complete within 4-6 weeks. (Didn't always happen, but the goal was to keep them short)

We had 16 different quality gates we needed to meet before a feature crew could be called "Done". Some of the meatier ones are below:


Quality Gates were the method we chose to ensure that 3,000+ people working on 700+ features on a code base of a bagillion lines of code (I really don't know how big it is, but you get the picture) ... that all that decentralized work could go on, yet maintain a consistent quality level overall.

While all the feature crews were working on their individual features, the entire division was managed to a set of iterations. I believe their were 14 iterations overall. The picture below depicts feature crews branch of the main branch, and integrating back into the main branch. Feature crews overlapped each other and overlapped iterations.


At the divisional level, we had Iteration Reviews, were all the teams would tell upper management what they expected to complete in the next iteration and what they actually completed in the prior iteration.

Next Chapter: Implementing the Process using TFS

Comments (13)
  1. Grant Holliday on TFS Performance Heat Map Reporting Services Report. Martin Woodward on Radio TFS #4…

  2. Gregg Boer, a program manager on the TFS work item tracking team has started a series of posts outlining

  3. 先月より、なぜか、Chapter 3 が二つありますが、それはご愛敬として・・・まだまだ続きがあるようですの Teams WIT Tools という TFS の開発チーム(主に WIT: Work Item

  4. Подгруппа разработчиков Visual Studio Team System, работающая над отслеживанием рабочих элементов в TFS,

  5. Before we talk about tracking progress, it might be useful to review the feature crew lifecycle as described

  6. In a previous post , I talked about the electronic status report. Basically, our status report was filling

  7. dendor says:

    Can you elaborate on the size of the branch? Do feature teams branch out the full code or is the code structured in a way that they can branch out only small parts?

  8. Kes veel ei tea, siis Workitem Tracking vahendite meeskond Visual Studio Team System -i arendusmeeskonnas

  9. Guino says:

    Hay una serie interesante de posts que nos explican de que modo la Division de Desarrollo de Microsoft

  10. A good read: Applying Value Up at Microsoft by Sam Guckenheimer (also available as 60-minute-webcast

  11. Part of my job is evangelizing Team Foundation Server adoption within Microsoft. A colleague recently

  12. In December, I had the privilege to be the “MVP in Residence” with the Team System product group. 

Comments are closed.

Skip to main content