With the introduction of the new Microsoft Visual Studio SCRUM 1.0 template, software development & project managers are now given multiple options for Agile that is supported by Microsoft. The “Agile” terminology is vastly over used by many and most agile teams, when examined closely, are in fact not Agile at all. Prior to the release of Visual Studio SCRUM 1.0, we were forced to utilize the Scrum for Team System (SfTS) template if you desired “scrict” SCRUM. If you desired to stay Microsoft, you had the ability to adopt Agile but do so without using key concepts exposed in SCRUM and this was done with the MSF Agile v5.0 process template.
If your head isn’t hurting now, it quickly starts after you’ve started trying to figure out how you’d like to setup your next TFS-based project. In today’s post, I will kick-off a series of posts that will occur over the coming days that focus on sharing the key differences between two process templates – Visual Studio SCRUM 1.0 & MSF Agile v5.0.
The first and rather more obvious differences you will find starts with the use of terminology. The terminology is exposed through the use of different work item types (WITs) depending on the template you chose. You can figure this out rather easily with a a quick look at the work item types available in each project -
Visual Studio SCRUM 1.0 -
MSF Agile v5.0 -
For your sake, I’m not going to just share what is already readily available in MSDN (MSF Agile v5.0 | SCRUM 1.0) around what each of these WITs are. Instead, I’m going to just ensure that you understand how each work depending on which project type you selected.
These two WITs are very similar and are at the heart of Agile development no matter what template you’ve chosen. The key concept for Agile development is the focus on the “backlog” which just represents the amount of work possible for your project. A key concept is that the backlog represents all possible work yet not any planned work in either case – it’s just a running list of work possible.
User Story types in MSF Agile v5.0 are rather generic forms of backlog and really minimize the use of SCRUM-based terminology. You will quickly notice that they provide a few key fields -
On the other hand, Product Backlog Item in Visual Studio SCRUM 1.0 add a few key SCRUM-specific fields that are often omitted by teams who are Agile yet not following “strict” SCRUM principles (you know who you are .)
As you can see, much of the data in the two work item types are virtually the same yet just given a different name. This might seem to be ridiculous but it is what it is – SCRUM has one term (Product Backlog Item) while Agile calls them User Stories.
For a quick highlight, I thought I’d share a quick mapping table to make it easy to follow -
The only major difference between the two is the inclusion of the field “Risk” in the User Story WIT. This might seem trivial and often overlooked by many development teams but it serves a big purpose. You can choose to ignore it; though, I’d challenge that figuring out what work to do within your release/sprint is between two items of the same business value but no risk assigned creates risk itself. The primary principles that we attempt to do anytime we are doing planning builds around the following diagram -
In today’s post, I wanted to kick-off what I promises to be a number of posts all related to what you should know before you choose to create a new Agile project in TFS 2010. This is a very important step as your decision could very well cause your project a lot of grief if you make a mistake and figure it out too late – this is a non-reversible action. The focus today was to share with you the first high-level item of difference – User Story vs. Product Backlog Item. In tomorrow’s post, I will talk about the differences around planning your development work…
Thank you for starting this series. It will be extremely helpful for us in making a decision "Which process template to use?". Eagerly waiting for your next post.
Your welcome! I hope you find it useful. Our team has spent a lot of time working the MSF Agile v5 process template to fit our needs though we are pretty excited by the SCRUM template. There are gaps, though...
I just posted the series outlining some things about the MSF Agile v5 and tomorrow I will wrap up the SCRUM 1.0 outline & comparison.
The goal was to answer the very question you ask - "Which process template to use"