Choosing a TFS Template

Which TFS Template Should I Use?

When I started managing TFS, this was one of my most urgent questions. I found it hard to get a straight answer, instead of “it depends” without any clear criteria. And even if you intend to fully customize your process template, you have to use an existing base template as a starting point.

If you’re wondering, the answer is: use the Scrum template. I'll confess that I have no experience with the CMMI template, since every team I’ve worked with has signed on to some type of Agile (at least aspirationally). Consequently, the choice was always between the Agile template and the Scrum template.

In Agile planning, the core unit for team planning is the “User Story”; in the Scrum template, this is called the Product Backlog Item (or PBI). The primary distinction between the process templates is how they treat the User Story / Product Backlog Item (most of the other workitem types are identical).

There are some small differences in the attributes that describe a User Story vs a Product Backlog Item, but you can easily customize the template to minimize this difference. The core differenciator between the two templates is that the Agile template lifecycle goes:

  • New - the work is proposed but hasn't been actively worked on.
  • Active - the work is in development
  • Resolved - development is complete and the work is being validated
  • Closed - the story is complete.

Whereas the Scrum template lifecycle is:

  • New - the work is proposed but hasn't been actively worked on.
  • Approved - analysts, PMs, or management have signed off on this work
  • Committed - the work is in development
  • Done - the story is complete.

So, the essential difference is that the Scrum template has a specific breakout for analysis and the Agile template has a specific state for testing.

Some might argue that combining the template states (New, Approved, Active, Resolved, Done) would give both analysts and testers their due — creating the best of both worlds. I disagree because on a mature team, testing should not be a separate state. Mature development teams are embracing automated testing and Test Driven Development. In this context, there is no separate testing state.

Of course, for most of the teams that I've worked with, explicitly moving work to testers is exactly how they work. Nevertheless, I believe that you shouldn’t build your automated workflow around processes that you are trying to abandon. A team that has no ambition to move away from a lifecycle that includes a separate testing state will probably benefit by using the Agile template. This process template is easier because work ready for testing is essentially in a test queue. However, many teams are able to successfully use the Scrum template by creating a separate testing task or assigning the story to a tester when ready. I suggest this as an interim solution, until testing is more fully automated.