Know the Latest Work Item ID // 

Knowing the latest work item is critical when importing and updating work items in bulk. Communicate with your team, or setup security accordingly, so that your team is not adding new items during your import process. Otherwise you may end up inadvertently overwriting or changing work items that are not part of your import.

Create a new query to pull all the work items in your collection so that you can get the last available work item id (@LatestWorkItemId). Hang on to the @LatestWorkItemId because you will need it when creating your import and update queries.

Use Separate Import and Update Queries // 

I like to get all my queries setup before doing the import. I am going to need a few different queries per work item type. For example, requirements (pbi or user story) have different fields than bugs, such as the description vs steps to reproduce fields. To make importing easier, create a query to import requirements and another to import bugs.

When importing work items the only state value TFS will accept on initial import is "New". After the initial import you need to update all the state values and re-publish. Another nuance with this is that Excel likes reformat your rich text fields after the initial publish. So if you have a nicely formatted description, Excel will muck it up and convert it to plain text. To get around this, create separate import and update queries. Your update query will not include any of the rich text fields so you don't have to worry about the text getting reformatted.

Here is an example of importing a list of active user stories. 

First create your query import and update queries and make sure you include the @LastestWorkItemId. We do this so that none of existing work items show up in our query results.

Next import the work items, set the state for all items to new, and publish. if you have not done this before see the MSDN article for details.

 Close the import query and open the update query. Notice that the update query does not have any rich text field columns. Update the state value from new to active and then publish. 

Note, we now have a new @LatestWorkItemId

One State at a Time  // 

This is where keeping track of the @LatestWorkItemId comes into play. Most likely you are importing work items with a variety of states (for agile: new, active, resolved, closed). Remember TFS requires you to have the state set to new on initial import, so you have to update the work items after the first publish. This would be simple if we did not have the problem of Excel reformatting our rich text fields (see above). Because of this issue, we need keep track of what items we are importing so we don't get lost. Here are the steps you can take to prevent losing track of importing and updating your work items with a variety of state values.

1. Manage your import files by state. For example Import_New.xls, Import_Active.xls, etc.
2. Make sure the import and update queries reflect the most recent @LatestWorkItemId
3. Import your first list of work items, publish and close Excel. 
4. Open your update query, update your values and publish. Before you close, get the work item id at the bottom of the list. This is your new @LastestWorkItemId.
5. Update your import and update queries to reflect the new @LatestWorkItemId (1666)

Summary //

Importing work items through Excel is pretty painless once you figure out a few of the nuances. These are some of the things I have ran across when importing lots of  work items with different state values. Hope this helps.

"This application is designed to help beginners grasp the powerful concepts behind branching when working with git."

1. MSTest Unit Testing Basics
2. XUnit
3. Mocking
4. Mocking Frameworks
5. Dependency Injection
6. TDD
7. Data Driven Tests
8. SSDT (Testing Stored Procedures)
9. Exceptions
10. Testing your JavaScript
11. Jasmine
12. Web Api Rest Services

1. Pull some configurable data values from a data source to be used in the Coded UI tests. These values could change depending on the environment (dev, test, staging, production).
2. Store a key/value pair to be used in later tests. For example, maybe access a web service that returns a dynamic value. We would need to keep that value available to be used in a test down the line.

Everyone on the team was experienced with development projects in one capacity or another. It was a mix of two veteran developers, experienced Scrum Master/Project Manager (a.k.a Product Owner), and a UX Designer. After a 2 hour crash course on product planning and sprint planning in Visual Studio Online the team was ready to begin. These are a few of the lessons learned during the process.

Anticipate the Culture Change // 

Even with a small team expect to be injected with some level chaos and culture change at the front end. Everyone brings their own baggage to the project and you need to spend the time with each other to agree on the process and ensure everyone understands the implementation of that process. The first 2 to 3 sprints on this project had more challenges because expectations where not in tune with each other. Once that got resolved things went much smoother.

Easy on the Detailed Requirements // 

As the Product Owner, and in this case the business owner, it was a challenge to refrain from detailed requirements up front as they are trying to keep scope under control with the customer. However it presented an issue as the details in the requirements do not take into account all the little changes that creep up during the normal development cycle. The Product Owner had to then go back and make changes to the details as stories made their way to the top of the backlog. So the Product Owner went back to the customer and the customer agreed to review the work one sprint at a time. Now they focus on just putting in the story title and quick description and worry about details as the story gets closer to development. This worked a lot better.

Sneaky Bugs and Changes // 

Part of developing an agile project is the understanding that changes in requirements are going to happen. It is best to add those changes into the backlog for prioritization in a future iteration. At first this concept was difficult to understand and implement because the customer and product owner would create changes hidden as bugs to them get resolved as part of the current iteration. This created unplanned work and as a result prevented the stories from being completed on time. Bugs are bugs and should be fixed in the current iteration. Changes should be added as a new story and put into the backlog.

Avoid Managing Lists and Complete the Iteration Review // 

As the team moved through the iterations I noticed the list of resolved work items kept piling up. Resolved bugs and stories sat in a queue iteration after iteration. At best this told me that the Product Owner was not closing out the work items. At worst the Product Owner was not completing any of the testing (we will cover testing in part 2). Of course the impacts would be testing the application all at once at the end and realizing they have mess load of bugs or issues to deal with. Something they needed to avoid. Make sure you complete the iteration review and the testing team or product owner is closing out resolved work items.

That's it for now. In my next post I will discuss testing and product quality. 

What is your experience with running a small development team through Visual Studio Online?

1) First create your Coded UI Test file and name it accordingly. When the popup appears select the "Use an existing action recording".

2) Visual Studio now creates a UIMap.uitest file (or uses the existing one) and generates the UI Actions from the existing recording.

3) Copy the UIMap.uitest file and paste it into your UIMaps folder or location of choice.

4) Rename the file to something meaningful. In this case I am calling in "UIMapSample.uitest".

5) Open the UIMapSample.cs file and rename the partial class using Refactor > Rename.

6) Check to make sure the UIMapSample.Designer.cs file and partial class have been renamed

7) Check to make sure the UIMap property in your Coded UI Test is not referencing the new UIMapSample class.

8) Delete the UIMap.uitest file

9) Run your test

It requires a few extra steps but it gets the job done. Happy Coded UI testing.

In this post we are going to add our company logo and change some of the styling. 

Customize // 

First let's add our company logo image to TFS. We need to put the image into the following folder:

"C:\Program Files\Microsoft Team Foundation Server 12.0\Application Tier\Web Services\_static\tfs\12\_content"

Next we need to modify the "TestSuite.xsl" file. That file is located in the folder:

"C:\Program Files\Microsoft Team Foundation Server 12.0\Application Tier\Web Services\_tfs_resources\TestManagement\v1.0\Transforms\1033" 

Open the file in Notepad and modify it. Here we are going add the image as part of the header with the following html.

Obviously you can modify the style in the rest of the document as you see fit. To view the changes, open a test plan from the test hub and click the icon to "Email or print test artifacts". 

 Things to Remember // 

• You can only customize the template on an on-premise instance of TFS
• You should copy and rename the xls file to something like "TestSuite-Original.xsl". If not, when you upgrade your TFS, the changes you made in the TestSuite.xsl file may get overwritten.
• You wont be able to customize the style per project, the style changes will effect all projects in your TFS instance

After consulting with the test team I found out that you need to have specific permissions set at the Area Path level and Project level.

Area Path Level // 

View Permission for this Node

Project Level //

View test Runs

View Project level Information  (Required to Connect to Project)

 Once we made the changes everything worked like a charm

Scenario // 

For the customers I work with, most of the teams have more work than they can handle and need some visibility into their overall work pipeline. Many times a request or change will come from a project managers or user, but they are not sure what team or project it should be assigned to. Setting up a single project team strategy would be hard in this case as it is difficult to share product backlog items (pbi, or user story if you are using agile template) across team projects within TFS. As a solution, we will use a multiple team strategy under a single team project. We will collect the pbi's and place them in an oversight queue that will be reviewed by either an individual or committee. Then these pbi's will get moved as they get assigned to teams and projects. We also need to setup security in way so that the individual teams don't have permissions to get in and monkey around with other teams backlog, queries, or code. 

Download // 

Download the document to walk through the entire scenario. You may not need the level of security as documented, but if you are setting up a multiple team strategy in TFS it's good to understand the concepts, capabilities, and restrictions.

Download the Multiple Teams Walk through using Team Foundation Server 2013

Other Good Resources // 

Visual Studio TFS Team Project and Collection Guidance

Agile Portfolio Management whitepaper

Add another team

Add team members

Portfolio backlogs

Creating groups for restricting access 

Step 1 //

Take your customized build template and save it to your local machine. For this example we are going to save it as “C:\TFS Build Templates\My Customized Build Template.xaml”

Open up Visual Studio > Team Explorer > Settings > Process Template Manager

Select your favorite process template and download it to your local machine. We will reference that template as @ProcessTemplateFolder to use in the steps further below.

Step 2 //

Copy the “C:\TFS Build Templates\My Customized Build Template.xaml” to the @ProcessTemplateFolder\Build\Templates folder.

Locate the Build.xml file that is in the @ProcessTemplateFolder\Build folder and open in Notepad. Add a new <ProcessTemplate item under the <TaskXml> node. It should look something like this:

<ProcessTemplate Type=”Custom” FileName=”Build\Templates\MyCustomized Build Template.xaml” Description=”This is my customer build process template” ServerPath=”$/$$PROJECTNAME$$/BuildProcessTemplates” />

Type: The type of file that is being uploaded. The following values are valid: Default and Upgrade for build template files and Custom for lab template files.

Filename: The local directory path and name of the file to upload.

Description: A short text string that describes the file to upload.

ServerPath: The path of the server that is running Team Foundation Server where the file should be uploaded. The only valid upload location is $/$$PROJECTNAME$$/BuildProcessTemplates.

For more information see msdn.microsoft.com/en-us/library/ms243875.aspx

Make sure you save your changes and close Notepad.

Step 3 //

You won’t be able to just upload the process template into TFS as is because a template of the same name already exists. So let’s change the name.

Locate the @ProcessTempatefolder\ProcessTemplate.xml file and open in Notepad.

Modify the XML in the <metadata> so that the <name> is unique.

Save the changes and close Notepad.

Open the Process Template Manager from TFS again and upload the customized process template.

Step 4 //

Create a new team project from Team Explorer. You should see the new customized process template in your list of available process templates.

Finally, create a New Build Definition on your new project. In the Process section click on the Show Details to the right of the Default Template. In the drop down list you will now see your new “My Customized Build Template.xaml” in the list.

Alternatively if you want to have your customized build template be the default you can change the settings accordingly. See step #2.

That is it. Now the build template will be available for every new project that uses the customized process template. Just remember to keep your customizations to a minimum for compatibility with future upgrades.