TFS 2010: MSF Agile vs. Visual Studio SCRUM 1.0 Smackdown
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.
Terminology Differences: Let’s just call it Potato versus Potatoe…
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.
User Stories vs. Product Backlog Item
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 -
Field Type |
Description |
| Title | This is provided to you in the infamous phrase of “As a <type of user> I want <some goal> so that <some reason>” as a guideline on how to write your user story title |
| Description | This is where one can provide a few more details around the request – keep in mind that often Product Owners are not technical and rather represent the business. |
| Rank | This is the stack rank of the backlog item |
| Story Points | This is probably one of the most “confusing” pieces of the User Story template as many read story points as actual estimate work. This isn’t the case – this is the guesstimate (often using techniques like planning poker or wideband delphi) of the total effort it might take to complete the user story according to the acceptance criteria. |
| Business Value | The primary objective of any development team should be, but often isn’t, to provide software that enhances the business. This field allows you to capture what the business value of this user story is. It should be obvious that high business value work should be completed before lower business value work. |
| Acceptance Criteria | I can’t bold this any bolder than already done. It is the foundation of what I’ve learned to be the key between success and everything else. This field is what the team, often QA, considers the required functionality needed to complete the user story. If all pieces of the acceptance criteria aren’t met, the user story isn’t considered “complete.” |
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 
.)
| Field Type | Description |
| Title | This is no different than in a user story though it is a required field. |
| Description | This is no different than the information you enter as the title in User Story - “As a <type of user> I want <some goal> so that <some reason>” |
| Backlog Priority | This is the stack rank of the the work in comparison to all other work in the backlog. |
| Effort | This is essentially the exact same as Story Points in user story and the technique used to provide are the same techniques – planning poker or wideband delphi. Beyond that, it sometimes might simply be a developer, test, or project managers estimates. |
| Business Value | The same as in User Story. |
| Acceptance Criteria | This is the same as in User Story. |
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 -
Differences between User Story & PBI work item types…
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 -
Summary
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…
Enjoy!
Thanks
-Chris