MSF Agile vs. Visual Studio SCRUM difference in the Workitem Types (WIT).

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

Xcopy command : Syntax and Examples

What’s Xcopy?

Xcopy is a built in command on Windows OS.  Copy is the other command we have on Windows, it can copy files from one directory to another. But it does not work for copying directories.  Using xcopy we can copy directories also.

Copy all the files in one directory to another directory.

Xcopy /I Source_Directory  Destination_directory

This would copy only the immediate files in the source directory to the destination. It would not copy files from sub directories. Adding /I switch will avoid the question to the user ‘Does the destination directory specify a file name or directory name on the target‘.

Copy a directory including all its files and sub directories to another location on the same drive or a different drive.

Xcopy  /S /I /E Source_Directory  Destination_directory

For example to copy all the files from D:\data\documents to the folderE:\Newfolder\documents we need to run the below command.

Xcopy /S /I /E D:\data\documents E:\Newfolder\documents

This command creates the folder E:\Newfolder\documents if it already does not exist. It also creates the same directory/file structure in the destination folder. If the destination folder already exists you do not need to add /I switch. If the folder does not exist and you do not specify /I you will be prompted to confirm if the destination is a filer or folder. This would cause issues if you want to run unattended or automated copying of files.

Copy files including hidden and system files.

The above command excludes hidden and system files from copying. If you want to these files also then you need to add /H option to your command. Then the command would be

Xcopy /S /I /E /H D:\data\documents E:\Newfolder\documents

/E option causes to copy empty sub directories to the destination folder.

If you add /H option the the command would also copy hidden and system files to the destination folder.

If you are trying to overwrite an existing file then add the option /Y so that you will not be prompted for confirmation for overwriting the file.

Copy files based on archive attribute

If you want to copy only the files that have archive attribute set, you can use /A and /M switches. Archive attribute indicates whether the file has been modified since the time the attribute was reset.
The command for this is:

Xcopy /A /I /S source_directory destination_directory.

The above command keeps the archive attribute set; It does not reset the attribute.

If you want to reset the archive attribute, you can use /M switch instead of /A. The command for this case would be:

Xcopy /M /I /S source_directory  destination_directory

Exclude files in the copying 
If you want to copy a directory to another location but want to exclude some files then you can use /EXCLUDE switch with Xcopy command.  You need to put the list of the files to be excluded in a file and then specify this file with the /EXCLUDE switch.

Xcopy /I Sourcedir  Destdir /EXCLUDE:filename

Example:
Copy the directory D:\docs to E:\newdocs\ excluding all pdf and mp3 files:

C:\>type 1.txt

.pdf

.mp3

C:\>Xcopy D:\docs E:\newdocs /EXCLUDE:1.txt

You can also specify the full names of the files. Each file name/pattern should be in a separate line.

The commands shown above can be used from batch files also. This command is available in Windows 7, XP, Vista, Server 2003 and Server 2008 editions.

Copy files based on modified date

Xcopy /D:dd-mm-yy  /I  sourcedir destinationdir

Example: To copy all the files in the directory ‘E:data’ that are modified on or after 1 st February 2011 to the folder ‘E:\backup‘

Xcopy /D:01-02-11 /I E:\data E:\backup

Regards

R.karthikeyan