Team Foundation Server & Visual Studio provide a solid foundation to start building good engineering practices around.

There was an interesting discussion about Agile vs Scrum Template for TFS 2012 on LinkedIn that I was interested in however LinkedIn has a bug and will not let me comment on that open group. So I will add my answer here.

The gist of the conversation is wither to use the Agile process template or the Scrum process template. I have seen good arguments for the Agile template if you are not doing Scrum however they tend to fall apart quite quickly as teams realise what agility really means and how their choice of the MSF for Agile Software Development process template is crippling their ability to inspect and adapt.. Let me explain; there are three templates available out of the box:

  1. MSF for CMMI Process Improvement
  2. MSF for Agile Software Development
  3. Microsoft Visual Studio Scrum


The funny thin is that all of these templates purport to be ‘agile’ however only one really is. Indeed two of the templates above support the CMMI process. Can you guess which? Its the ‘MSF for CMMI’ and the ‘Visual Studio Scrum’ template. I have had a number of… discussions … with the folks that own MSDN: Work with team project artifacts, choose a process template about its inaccuracies and false choices and some changes have been made. However I have issue with one particular statement in there:

The Agile template is designed to support Agile development for teams that don’t want to be restricted by Scrum.

imageI disagree that the ‘MSF for Agile Software Development’ template is suitable for any team that wants to be agile and I vehemently disagree that the Scrum template is ‘restrictive’. My reason is that the ‘MSF for Agile Software Development’ template is not in any way agile and in fact enshrines many anti-patterns for agile teams. I will get to them, but first a little history. The ‘Agile’ template is properly called the ‘MSF for Agile Software Development’ template and the MSF part if important. Microsoft Solution Framework (MSF) was designed by Microsoft Consulting Services (MCS) to help them deliver software to customers when consulting. The MSF for Agile template was originally an attempt to implement that non-agile methodology (don’t let the work Framework fool you) in a more agile manor and it failed (oh it gave managers a false sense of false agile; vanity agile.)

There are two main issues with the ‘Agile’ template:

  1. Bugs are not on the backlog – As any good consulting team (sarchasm) knows you must hide your bugs from the customer and this template promotes that bugs are triaged separately to Stories. Yes you can change this to add bugs to the backlog, however the investment to fix all of the other assets to include this is financially unviable.
  2. Resolved (Code Complete and Unit Tests passes) – Yes I know that many teams still like to create a wall between Code and Test but to enshrine it in the template forces all teams to follow that line. And I would suggest that this ‘wall’ is one to work to be rid of for an agile team.

While these are the big important ones there are a number of smaller paper cuts that force, if only by name, a team into a particular mode of working:

  • Story Points – Story Points are just a complimentary practice. While I am a supporter of Story Points and I encourage teams that I work with to use them they are by no means the only method of estimating in agile. This should have a more generic name, like maybe ‘Effort’ that allows the team, or organisation, to collectively decide how they are going to do estimation.
  • User Story – Another complimentary practice and one that you will not find mentioned in the Scrum Guide. While user stories are an effective tool to help you decompose your work they are by no means the be all and end all. Having the ‘Requirement’ type called User Story makes folks feel that every one should have a ‘As a… I want… so that…’ which is just not the case in any of the agile processes. Would it not be better to have a more generic term, a base class if you will, from which you can form any sort of definition of our work?

I would not want to force, via a template, any of the above ideas on a team o organisation. They are not required to be successful at agile however being able to break walls between departments and triage bugs with the rest of our backlog I would argue is. Don’t get me wrong, I like practices like Story Points and User Stories and they are right for some teams, although not all. If you really want to be able to ‘let the team decide’ on the practices that suit their circumstance, experience, technology and choice then you need to stay away from MSF entirely.

So what is the answer? There are two MSF template and one Scrum template but I am not doing Scrum! For me, and what I recommend to most folks is that they download the Scrum Template… change the name to the ‘Visual Studio Agile 2013’ template and reload it. Problem solved.

The Scrum template was designed to be as generic as possible, rather like the Scrum framework itself, while still embodying the common workflow and lexicon of Scrum. Bugs are on the backlog, one state for the team working on something, no push to a particular practice.  Almost universally the terminology and workflow of the Scrum framework is understood by teams doing agile, MSF… not so much.

I always recommend that folks start with the Visual Studio Scrum template as a base and customise from there. And there are a few customising that I like to see teams make if they need them, especially to help adoption:

  • Completed & Original Estimate – The Scrum template only has ‘Remaining Work’ on a Task as this is the only metric that Scrum requires. However there are many teams that gain value through other metrics and the Scrum Guide does not say anything about not using them. I often add these two fields to the Scrum template for teams.
  • PBI Type – Often organisations like to differentiate between Functional , Technical, or Regulatory PBI’s and this is another field to add. Making sure of course that it becomes a dimension in the Cube.
  • Team Field – Often the case for long term users of TFS is that they already have made good use of the Area Path field. Now they need to use it for team? Well, no… create a Team drop down and with a little out-of-box wiring you remove the relationship between Team and Area Path.

These customisations are non-intrusive and have a limited impact on reporting and upgradability. I spend a lot of time at customers migrating them from MSF for Agile Software Development to the Microsoft Visual Studio Scrum template and while it is not that hard to do it does take time and money.

Bottom Line: Choose the Microsoft Visual Studio Scrum process template if you don’t want to be limited by MSF.

What other customisations do you make to your Scrum template to support your lean-agile process?

Agile vs Scrum Process Templates in Team Foundation Server was last modified: January 23rd, 2014 by Martin Hinshelwood

-Every company deserves working software that successfully and consistently meets their customers needs on a regular cadence. We can help you get working software with continuous feedback so that your lean-agile teams can deliver continuous value with Visual Studio ALM, Team Foundation Server & Scrum. We have experts on hand to help improve your process and deliver more value at higher quality.