A few years before I left Microsoft UK to join RippleRock, I remember having a conversation with one of my future colleagues about RippleRock’s value proposition and their response was simply this:

“We will make your Agile project successful”

Now, of course they went on to caveat that this requires buy-in from the business among other things but RippleRock’s specialism in both Lean/Agile process and ALM/DevOps tooling give them a unique position among the Microsoft UK Partners.

Since I joined the team, RippleRock have continued to deliver on that statement but there is one thing that comes up project after project and that is the difficulty and inaccuracy teams encounter with gaining usable insight into their development process . On top of that, most organisations insist on reporting on metrics that will only drive the wrong behaviour and cause dissatisfaction in the team.

Some examples include:

• How accurate are the team’s initial estimates?
• How many bugs have the testers raised?
• How many lines of code have been written?
• Comparing velocity across teams
• Cost per team/Story Point

This type of behaviour and the difficulty in authoring reporting (initially in TFS/VSTS but also in Jira etc.) caused RippleRock to develop SenseAdapt.  The name obviously comes from the tool’s aim which is to allow teams to ‘sense’ what is going on in their project and ‘adapt’ their process in order to improve things.

Some examples of what SenseAdapt is visualising for your team:

• When will this project complete?
  • Based on real historical data and using Monte Carlo simulation to predict the likely range of completion dates.
• How healthy is our backlog?
  • Are we working on the right things?  Have we given the team all the information they need to do their jobs?
• How much ‘sludge’ is in our backlog?
  • Typically, there is lots.  This is work that never makes its way to the top of the backlog and will never be addressed, it just sits there, growing and demoralising the team
• Where are the bottlenecks in our process?
  • How can we improve the flow of value to users

^{Figure 1: Currently available charts in SenseAdapt}

Our clients have been using SenseAdapt for five months and the insights that it brings to teams and management is leading to real change in both process and project scope as they rely less on the current subjective reporting and groupthink.

Recently we came up with what I think is the perfect description of what RippleRock are enabling with SenseAdapt:

Process Telemetry

Whilst we use tools such as Application Insights and Dynatrace to monitor a running application or website, SenseAdapt monitors your development process and helps you to see and then take action to improve the system.

If you are interested in a demo or a trial of SenseAdapt or want to discuss what it could offer you then contact us.

If you are UK based then come along to our free event at Microsoft Campus in Reading on 6^th May where we will talk about all this and much more.

More details and signup here:

Engaging the Business with Team Foundation Server: From Idea to Live – Microsoft Campus, Reading (Friday 6th May 2016)

More information on SenseAdapt available on http://www.senseadapt.com

Cheers,

Richard

We recently had an issue where we were seeing different behaviour being exhibited by two different Visual Studio Team Services accounts when testing SenseAdapt.  We closely compared the settings of the two accounts and wondered if it could have been down to them being hosted in different datacentres.

If you have a look at Microsoft Azure - Services by Region, you can see that VSTS accounts will be in one of four regions:

• North Central US (Illinois)
• South Central US (Texas)
• West Europe (Holland)
• Australia East (NSW)

If you’re in the UK like us then you might expect your account to be stored in West Europe but if you created your account before the end of October 2014 (when VSTS was added to W.Europe) then it is likely that it is in one of the 2 US regions.

To check, you can navigate to your account settings by clicking on the gear icon at the top right of your web access or stick an _admin at the end of your account url.

https://<youraccount>.visualstudio.com/_admin

Click on the Settings tab or navigate to the url:

https://<youraccount>.visualstudio.com/_admin/_home/settings

In the settings you should see your Azure Region listed (you can see that mine is North Central US)

At the time of writing you cannot change this region setting yourself so to do so you will have to contact Cloud Services Assisted Support.  However, according to UserVoice: Change Visual Studio Online account region, Microsoft are working on a self-service process as of Feb 2016 so keep an eye out for this changing.

Cheers,

Richard Erwin

RippleRock are developing an awesome tool for providing realtime, actionable visualisations of your project data.  If you’re wondering why your backlog is such a mess, want to understand how you could improve your Agile/Lean development process or simply want to predict when your project will end, then you should check out SenseAdapt.

SenseAdapt works with Team Foundation Server and Visual Studio Team Services (keep an eye out for a preview on the new VSTS Marketplace soon) and we’re experimenting with a Jira version too.

To develop SenseAdapt, we use our own project data, so SenseAdapt is helping us to improve and adapt the process we use to develop SenseAdapt!

The problem is that we need real data in both VSTS and TFS and as we recently consolidated a VSTS project into our on-premise TFS 2015, we wanted a one-way sync of Work Items between the two systems.

There are options of course:

• Commercial Product like TaskTop or OpsHub
• Roll our own, with a TFS server side plug-in (much the way we do with TFSRippler)
• A free tool such as the TFS Integration Tools.

I wanted something implemented quickly and cheaply so that’s why yesterday I installed the TFS Integration Tools.  If you have ever used TIT (they really should have thought about that acronym) then you’ll know that they are……er, interesting?

Last released in March 2012, they know nothing of TFS 2013/2015 and VSO/VSTS was the TFS Service Preview back then.  My installation was on Windows Server 2012 R2 with SQL Server 2014 Standard SP1 and TFS 2015 RTM (No update 1 on this instance for testing purposes)

I knew that I needed to install the TFS 2012 Team Explorer so that the Integration Tools could talk to my server using the older object model.

I also knew there was a problem with this setup that needed a little registry change.  The error you will see is:

“This tool requires the TFS client object model.  Please install Team Explorer 2008, Team Explorer 2010, or Team Explorer Dev11 and run setup again”

An old blog post by Willy Peter Schaub shows that the easiest way to fix this is to paste the following into a .txt file, rename to .reg, and double click.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\11.0\InstalledProducts\Team System Tools for Developers]

@="#101"

"LogoID"="#100"

"Package"="{97d9322b-672f-42ab-b3cb-ca27aaedf09d}"

 "ProductDetails"="#102"

"UseVsProductID"=dword:00000001

I was off and running now so I kicked off the install that I’ve done many times in the past and selected to include the TFS Integration Service

For the database server name, i just put a ‘.’ as I was going to use the default instance (SQL 2014 Standard)

Unsurprisingly, something went wrong but I aborted the install without really paying attention, assuming I messed something up.

So I started the installation again, paying more attention this time but I received a different error:

Database Error: Cannot read TFS Integration Tools database version number

It turns out that the failed installation had created the database Tfs_IntegrationPlatform but had not cleaned it up again during rollback.  That helpful message meant that I needed to go into SQL Management Studio and delete the database.

We were off again and everything seemed good until the error message that I received originally showed up again.

Error -2147217900: failed to execute SQL string, error detail: Valid values of the database compatibility level are 100, 110, or 120., SQL key: CreateDatabaseScript SQL string: EXECUTE sp_dbcmptlevel [Tfs_IntegrationPlatform], 90;

This one was trickier.  There was an ooooold forum post by Bill Essary at Microsoft saying that they were aware of the issue but didn’t have a fix as yet.  A few others suggested that the problem went away when they retried the install.  After the 3rd time, I accepted it wasn’t going away.

Making an educated guess, i assumed that the integration tools were not compatible with SQL 2014 so I decided to install a named instance of SQL 2012 Standard SP3 on the same server.

Passing in .\INTEGRATION as the database server\instance meant we were finally installed!

Onto the next problem

I created a new configuration and selected Team Foundation Server\WorkItemTracking.xml as my template.

I didn’t bother reading the docs as I was still sceptical that this was going to work so I just chose Custom workflow, ContinuousAutomatic frequency, Unidirectional direction.

Next, I chose my on-premise TFS 2015 server as the Left Source and my VSTS account as the Right Source.

I had forgotten that the account running the Sync/Migration had to be in the Service Accounts Group.  On-premise you have to use tfssecurity.exe to add your account to that group but I suddenly thought, “there’s no way VSTS will let me do that”, so I expected it to be game over.

I tried:

tfssecurity.exe /g+ “Team Foundation Service Accounts” n:my@emailaccount.com /server:https://myaccount.visualstudio.com

and unsurprisingly got

The requested operation is not allowed

Kind of obvious as VSTS is not going to allow me to be a Team Foundation Admin or Service account so I had one last stab:

tfssecurity.exe /g+ “Project Collection Service Accounts” n:my@emailaccount.com /collection:https://myaccount.visualstudio.com/defaultcollection

Amazingly, that was successful

I repeated the process for my on-premise server and I was off.

Now, the tools are installed and running but as usual, it has thrown a hissy fit on the first pass.

Application Error: 0 : A failure occurred while trying to load the C:\Program Files (x86)\Microsoft Team Foundation Server Integration Tools\Plugins\Tfs2008WITAdapter.dll Plugin:
System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.

and

Application Error: 0 : A failure occurred while trying to load the C:\Program Files (x86)\Microsoft Team Foundation Server Integration Tools\Plugins\Tfs2010WITAdapter.dll Plugin:
System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.

and

Application Critical: 0 : [27/01/2016 19:07:38] System.InvalidOperationException: Specified element is already the logical child of another element. Disconnect it first.

After all that, those errors looked like they could be terminal but I found an article that states that removing any files with 2008 or 2010 in the name from the following folder:

C:\Program Files (x86)\Microsoft Team Foundation Server Integration Tools\Plugins

will allow the Integration Tools to progress.

Great source for all things Integration Platform: TOC: TFS Integration Tools Blog Posts and Reference Sites

And we’re off and running with 1-way sync between TFS 2015 and Visual Studio Team Services!

Cheers,

Richard

One of my clients recently moved to Visual Studio Team Services (formerly Visual Studio Online/VSO) and decided to share an account already in use by another part of the company. 

Their developers were mainly licensed with MSDN and so were able to hop straight on there and start working but the ScrumMasters, Product Owners and testers were not and they wanted to know how they should license those non-developer users.

I realised that a lot had changed since the last time I looked at the VSO licensing so it’s worth a quick blog in case others were bumping into the same issue

Free Users

When you create a Visual Studio Team Services account (myaccount.visualstudio.com) you get 5 free users.  This means that if you’re creating the account for some personal dev project, you could invite 4 friends to contribute and nobody needs any licenses for anything!  Go and grab Visual Studio Code or Visual Studio Community for free and get stuck in to coding/building.  Grab the Office Plug-in and your “Product Owner” can hook the backlog and other queries into Excel (you need an office license obviously!).

The free users are “Basic” users - we’ll talk more about this later.

My client had joined an existing account so when they navigated to:

https://myaccount.visualstudio.com/_user

all the free users had been assigned so we needed to add some other types.

MSDN Users

Anyone with an MSDN subscription (Enterprise\Professional\Test Professional\Platforms) has an included Client Access License (CAL) that can be used with on-premise Team Foundation Server and/or cloud hosted Visual Studio Team Services. 

You can be added to any number of VSTS accounts at the Basic level  so I can be on my personal account, the RippleRock account and client accounts)

Stakeholders

Free Stakeholder licenses are great, as the name suggests they were added to allow anyone who has an interest or a say in the project to view project information without the need to buy them a license.  If they simply want to add some things to the bottom of the backlog for consideration by the Team/Product Owner, or view project progress, then great, hook up as many as makes sense and away they go.

However, many teams will think, “my ScrumMaster doesn’t need a license as they’re not writing code”, or “my PO doesn’t need a license as they only want to work with the backlog”, but that generally isn’t the case.

There is a good comparison of Stakeholders and Basic Users here:

Visual Studio Team Services Feature Matrix

In summary, Stakeholders:

• Can view, create, edit and query (most) Work Items via the web client
• Cannot access Work Item Queries from Excel
• Have limited functionality on backlogs and boards (crucially the cannot re-order items which is pretty critical for PO/SM)
• Have no access to version control/builds
• Cannot be project administrators

Additional Users

Prior to VSO/VSTS, if you needed to license a non-MSDN user for TFS, you simply bought a Client Access License (CAL) for TFS. 

CALs were not very expensive but they could be bought with or without Software Assurance and one problem was that users often bought the license only (without SA) which meant it was tied to a specific version of TFS.  This meant that when the team wanted to upgrade to the latest version of TFS, it could become a more costly procedure as new CALs had to be purchased.

With VSTS, you can still buy a CAL but it is usually significantly cheaper and more flexible to add users through VSTS (which also allows them to access both on-premise and cloud hosted) and pay monthly for what you need.

You need to set up payment on your account and choose how many users you need.

Pay for users accessing your account

Pricing f0r additional users is pretty reasonable.  Remember, the first 5 users are free, so if you need 10 users it will cost about £20 per month (each user over 5 is approximately £4, or more accurately $6).  If you need 15 users then it’s about £48 per month in total.

First 5 users: FREE
Users 6 through 10: $6 each
Users 11 through 100: $8 each
Users 101 through 1000: $4 each
Users 1001 and above: $2 each

At the time of writing, if you have an Enterprise Agreement, then all additional users are only $4 per month which makes it about 23 Basic users for only 50 quid a month!

For more details and a handy calculator, see:

 Visual Studio Team Services Pricing

That covers Basic users but what about VSO Professional or VSO Advanced licenses?

In short, they’re gone!

Brian Harry covered this in his blog in September:

September pricing and licensing changes

Now, you simply provision a Basic user and then purchase add-ons for any additional functionality that they need.  At the time of writing this additional functionality is limited to Test Manager (that used to be included with the Advanced license) but the new marketplace will mean that much more will be available in the future.

Test Manager

While we’re at it, where’s Team Explorer 2015?

It’s gone too!  The main reason people installed Team Explorer was to get the incredibly useful Excel integration but there will be no Team Explorer for Visual Studio 2015.

You can install the free Visual Studio Express or Visual Studio Community to get your Team Explorer or you can continue to use Team Explorer for Microsoft Visual Studio 2013 which will happily connect to VSTS/TFS 2015.

If you simply want the Excel integration then you can grab the new TFS Office plug-in

More information: TFS Office Integration Installer

Download: Microsoft Team Foundation Server Office Integration 2015 Update 1

Resources

As always, the Visual Studio 2015 Licensing White Paper usually has any information you need and is also handy if you’re having trouble sleeping.

Cheers,

Richard

*Update April 2016 – If you are interested in this area and based in the UK then register for our free event at Microsoft Campus in Reading on 6th May*

About 18 months ago I wrote a blog post on TFS Reporting and it has been one of the most popular on my blog for some time.  I think that is mainly because reporting in TFS is so difficult but many teams realise the importance of accessing the data that it contains. 

Although 90% of that post is still valid in the new world of Team Foundation Server 2015 (Update 1) and Visual Studio Team Services, there have been some fairly significant enhancements and also my approach to reporting have changed too.

Visual Studio Team Services Vs. Team Foundation Server

At the time of my first post on this subject, the cloud-hosted version of TFS had just been renamed to Visual Studio Online (VSO) from Team Foundation Service Preview and reporting was one of the few missing features as it did not have a data warehouse or SQL Server Reporting Services. 

However, at the end of 2015, VSO has been renamed again to Visual Studio Team Services (VSTS) and those missing features have been added (custom Process Templates), become obsolete (SharePoint Integration) or in some ways surpassed the current on-premise version (PowerBI reporting, Release Management).

This is because VSTS is evolving rapidly and is updated monthly whereas we typically see on-premise updates quarterly and it could take IT many more months to plan applying the update.  At RippleRock, we run all our internal projects on VSTS and for me it is fast becoming the obvious choice over on-premise as long as you can get over the idea of your project data and source code being stored in the cloud.

So what has changed in the last 18 months?

Charting

Admittedly, Charting hasn’t changed massively but a historical set of charts was introduced which made the feature much more useful.  Take a look at the Trend Charts in addition to the Snapshot charts

I am not going to repeat the details of creating a chart as they are well documented on MSDN:TFS2015/VSTS Charts.  One thing I will note is that you can only create a chart from a Flat Query which can be a little limiting.  Pay close attention to the included Columns and Sort Order of your query too, as they will have an impact on what is available to you in the chart options.

Dashboards

In TFS 2013 each team had a home page where Team Administrators could pin queries and charts specific to that team.  However, these homepages could quickly become cluttered and had to serve multiple purposes making it difficult to filter the data you wanted to see.  With TFS 2015 Update 1 (and VSTS since October 2015) this has changed to allow users to create multiple dashboards per team.  So you could easily have a bugs dashboard, stakeholder dashboard etc.

Again this is well documented on MSDN: TFS2015U1/VSTS Dashboards.  Just click the green ‘+’ beside the Overview dashboard and start creating the boards you need.

Each board can have a number of configurable widgets to allow you to only show information relevant to the board.  At the time of writing there are about 15 widgets that can be added to a dashboard by clicking the ‘+’ on a green circle at the bottom of the dashboard.

What is exciting for RippleRock is that you will soon be able to write your own widgets and we will make our SenseAdapt (see below) charts available to your dashboards to give realtime actionable metrics.

Power BI

Power BI is probably the biggest development since the last post and typically the feature was first announced shortly after I published the blog making it almost instantly out of date.

To be fair, at that stage there wasn’t a lot in there, really just some nice metrics for Git users in TFS -  No TFVC, No Work Items, No Test Results.  A lot has been added since then and there is more to come!

Once you’ve signed up, it is pretty easy to connect Power BI to your VSTS account (just remember not to add the .visualstudio.com when you enter your account name).

When choosing your project(s), be careful to spell it correctly as it doesn’t appear to check if the project exists and you’ll just get blank data.

Importantly data is not live, this is similar to the OLAP cube in TFS which was refreshed every 2 hours by default.  The last time I checked, PowerBI updated data every 24 hours but this is configurable.

Now you can interact with data in a number of ways.  There are the pre-created reports, natural language queries (how many bugs were created this week?) and then you can create your own reports much like you do with Excel and SSRS.

On premise support for PowerBI is not there yet.

However, it can be done by pointing the cloud hosted PowerBI at your on-premise data warehouse.  Obviously this adds some complexity around access to a server behind the firewall and in my eyes doesn’t get beyond the problems that we see with 3rd Party BI Tools.  I think this will become the main reporting option for TFS but for me, it’s not fully baked yet.

SenseAdapt

SenseAdapt is a custom reporting tool for TFS that was born out of both the frustration at the difficulty of visualising data from TFS and the realisation that all too often the data in the system was poor.  We needed something to allow us to understand how teams were using TFS and to surface issues that could be tackled.

My colleague, Bazil is our Product Owner and has a great blog post on SenseAdapt

SenseAdapt: Data-based, Actionable Insight

SenseAdapt can be installed on an on-premise Web Sever (even the TFS box if you wish) or it will be available as a VSTS Extension (see below).  We use the TFS API and so all the data is live and it does not rely on a the data warehouse.  The UI is web based and can be accessed using any device.  All the charts are interactive so you can see much of the data that underpins the chart.

The tool will help teams improve their Agile process but for me, the outstanding feature is the ability to predict project completion dates.

If you have a fixed delivery date, understanding where your project is predicted to finish with the current backlog and completion rate will allow you to make difficult decisions about the scope of the project.  You might not like what you see but it’s better to know ahead of time if there is likely to be a problem with delivery.

Contact me or Bazil if you’re interested in understanding how SenseAdapt can help your team improve.

VSTS Extensions

The TFS Marketplace was in introduced in November 2015 and I expect to see this expand massively over the next 6 months with both free and commercial plug-ins.  We have SenseAdapt almost ready to go (give me a shout if you’re interested in trying it on your account).  At the minute, it is VSTS only but I expect to see extensions on premise in the next few updates. 

VSTS Marketplace

3rd Party BI Tools

We  recently worked with a client who made extensive use of Tableau (and others who use QlikView and Cognos) which seems to be the gold standard in BI tools.

While things started well, the major issue was users understanding the TFS data warehouse.  It could be incredibly difficult to get the data you wanted which kind of defeats the purpose of having this beautiful BI tool. 

So, while you can do it and get good results, it is not an easy option and unless you already have the tools, it can be very expensive.

REST API on Premise

Just a note that TFS 2015 brought the REST API to on-premise TFS. 

“The REST APIs enable a lightweight way to work with Team Foundation Server from virtually any device, platform, or technology stack. You can create and query work items, queue a build, get recent team room messages, access source code, and accomplish almost any team or code management task.”

In fact the TFS API is now available via NuGet in 4 different packages.  Check out Buck Hodge’s blog post on the subject:

NuGet packages for TFS and Visual Studio Online .NET client object model

• Microsoft.TeamFoundationServer.ExtendedClient This package contains the traditional TFS/VSO client object model that uses the SOAP API. You will need it to get full access to the work item tracking object model, version control, test management, and more. If you’ve used the TFS/VSO client object model in applications before, this is the one you’ve used. Because not every API is available in TFS 2015 or VSO currently as a REST API, there are going to be cases where you must use this package. Similarly, there are new features that have been built with only REST APIs for which you will need the Client package.

• Microsoft.TeamFoundationServer.Client Here you’ll find convenient .NET wrappers for our REST APIs for build, team rooms, version control, test case management, and work item tracking. You can of course call the REST APIs directly without using this library. You will encounter cases where an API is not available in this package and have to also use the ExtendedClient package.

• Microsoft.VisualStudio.Services.Client If you need to access account, profile, identity, security, or other core platform services, you’ll need this package.

• Microsoft.VisualStudio.Services.InteractiveClient This package provides the library necessary to show a user an interactive prompt for credentials to sign in. If you are using basic authentication, personal access tokens, or OAuth, you won’t need this.

Richard

A common scenario I encounter is when a client has some existing assets in TFS or VSTS and they want a clean slate, to consolidate backlogs or to use a new Process Template.  More recently it is because they want to move their backlog to Visual Studio Team Services (formerly Visual Studio Online)

If you want to migrate source code history then you’re looking at something like the TFS Integration Tools for on premise TFS or the OpsHub Visual Studio Online Migration Utility for VSTS.  They will also migrate Work Items and their links. 

There are other open source tools for migrating Work Items out there such as Total TFS Migration but they are not always maintained and there are some commercial tools which can be expensive.

If the situation is right then I often find Excel is the simplest mechanism to copy Work Items from one Team Project to another.  I have also used the same technique to successfully move items from Jira, Trello and other systems.

However, using an Excel input list is not a perfect solution on its own.  Off the top of my head, you’re going to have to consider:

• New Work Item IDs
• Work Item Links
• Creation State
• Hyperlinks
• Attachments
• Lost Work Item history
• Discussions
• Test Steps
• Created Date
• Closed Date
• Area Paths
• Iteration Paths

We’ll look at some of those later in this post but let’s get some Work Items copied to begin with.

The simplest scenario is if both source and target projects use the same Process Template so that all your fields match (eg. copy the value of Microsoft.VSTS.Scheduling.Effort from source to target). 

If the templates don’t match then you’ll have to do some planning to understand how the fields match  (for example Microsoft.VSTS.Scheduling.StoryPoints to Microsoft.VSTS.Scheduling.Effort) or fields that might be missing (eg. Microsoft.VSTS.Scheduling.CompletedWork or Microsoft.VSTS.Scheduling.OriginalEstimate).  If the fields are missing then you could consider adding them to the target process template, storing the information somewhere else or simply leave it behind.

Create a Query

First up we need a query to return all the items you want to copy. 

Ask yourself, are you going to copy closed, done or removed Work Items.  Often clients do but don’t realise that it’s not going to give them the historical view that they expect as the Closed Dates will be different.  I’d encourage you to leave them behind and retain the old project for a while.

If you have any links between Work Items that you wish to preserve then it needs to be a Tree Query.  We could hook up links with PowerShell later on (mental note to blog about that later) but I like to use Excel if possible.

A query like this is going to bring back everything in a hierarchical structure regardless of the State or Work Item type. 

Something like this will omit Done or Removed Work Items but just be careful that you don’t lose orphaned items or perhaps an odd situation where you have active child items whose parents have been moved to Done.

You may need to play around with the query to get what you want. 

Importantly, click on Column Options and choose which fields you wish to import.

Then choose your sort order.  Backlog Priority followed by ID is probably a good shout.

Copy your Query to the target project

We have our query to export the data we want but now we need to add that to the target project so that we can import the data.

Open the source project in Visual Studio/Team Explorer and navigate to your query.

Click on Edit Query

And Select File-> Save As…

We want to save our query to a file (*.wiq), somewhere we we can find it.  Open the file in a text editor of your choice (I like Notepad++) or you can do it in Visual Studio as long as you select the Open With drop down.

Edit the Server URL and the Team Project Name in the wiq file and save it again. 

Now open Visual Studio and connect to your target team Project. 

Select File->Open->File…

Navigate to your *.wiq query file.

Select Save As…

and select your new project as the target server. 

The query should now be available in the target Team Project.

Open your Query in Excel

Open Excel, navigate to the Team tab, hit New List and select your query in the source Team Project.

Open another instance of Excel (hold down the Shift key when you click the shortcut) and open the query in the target Team Project.

In the source project we can see the Work Items we are going to migrate.  Note that the Parent/Child hierarchy is represented by multiple Title columns.

This hierarchy is missing on the target query so we need to add as many levels as we need.

On the Team ribbon, select Add Tree Level, in my case I needed three more levels to my hierarchy to represent Epic-Feature-PBI/Bug-Task.

Create new columns

Now we need to create some space where we can store related information that we will not publish to the new team project.  You could add custom fields in TFS to store this information but I like to keep the template as clean as possible.

Right click on the column in Excel and Insert columns where you need them.

Repeat the process to store things like the Old Id, the Old State (all new items will be created as New/To Do etc), Old Area Path and so on.

I like to colour these columns (it’s always orange for some reason) so that it is clear that they will not be published back to TFS and only live on this spreadsheet.

Clicking Choose Columns in the Team ribbon allows you to re-order the columns including the non-TFS ones.  This will make it easier to copy and past in the next section.

Copy source Project data

Begin the process of copying the data from the source sheet to the target sheet.  When we hit Publish on the Team menu, new Work Item IDs will be generated for us in the new project and the Parent-Child links will be created.

Edit the copied data

Now we need to alter some things like the Work Item State.  The TFS Process Template will not allow us to create Work Items in a non-starting state so our items will be New or To Do for example.  We need to filter on the Old States we want to edit.  Click the drop down on the column header and select the first state to edit.

Now we see only the items we need to change.  Change and then fill down the value in the State column (In Progress in the example below) and publish back to TFS.  Repeat the process for all the states returned in your query

You will also need to come back and do this for things like Area Path and Iteration Path if you haven’t already created them in your new project.  Just save this spreadsheet and you can refresh and publish from/to TFS anytime.

Conclusion

So now we have our basic data in our new Team Project along with the Work Item hierarchy.  For many this will be enough but for others, there will be hyperlinks to SharePoint documents, attachments and more that need to be migrated.

Colin Dembovsky has a great blog post - Bulk Migrate Work Item Comments, Links and Attachments – which provides a PowerShell script which is really helpful. 

I want to talk about some of the other issues such as Test Steps and Area Paths in another article but for now it’s time for Christmas.

Cheers,

Richard

Last month Microsoft finally put the new VSTS (formerly VSO) Release Management into public preview.  If you haven’t checked it out yet then just navigate to your Team Project and you should see a new top level menu option – Release*

The asterisk means that it is still in preview.

We’ve been using this for a while in our own internal development while it was in private preview and we think our clients are going to love it.

At the minute, this web based UI is VSTS only and it didn’t make it into TFS 2015 Update 1 so fingers crossed for Update 2.  If you want to read more about upcoming features for VSTS and TFS then check out the Visual Studio Team Services Features Timeline.

VSTS Release Management can target both on-premise machines and cloud based VMs or Websites so you’ll probably want to hook up your MSDN Azure subscription to VSTS if you haven’t already.

Navigate to the admin page for your Team Project by clicking the gear icon and then select the Services tab.  The url will be something like this:

https://<accountname>.visualstudio.com/DefaultCollection/<ProjectName>/_admin/_services

Add a New Service Endpoint and select Azure

Then you will need your MSDN Azure subscription details to complete this so grab your subscription ID, subscription name and management certificate by downloading your publish settings:

https://manage.windowsazure.com/publishsettings/

Copy everything between the quotes:

and paste it into the new Azure Connection dialog.  Give the connection a name to help you recognise it in case there are multiple Azure connections associated with the project.

Click OK and your account should be ready to deploy.

Now when I create my Azure Web App Deployment, my Azure Subscription will be available in the drop down

Cheers,

Richard

Writing queries in TFS is really simple, right?

• Flat query showing high severity Bugs with low effort estimation in the modelling area?

“No problem.”

• Direct Link query showing only Backlog Items that do not have an associated Test Case in a Ready state? 

“Here you go…”

• Tree query showing a hierarchy of Epics with a high business value with Features, PBIs and Bugs that are in Release 2? 

“Errr, let me think about that!”

That’s why with TFS 2013 I always found it easiest to open up my Backlog, change the view to show a tree, for example Features to Tasks…

Then I could hit that little Create Query button…

name my query…

And Bob’s your uncle, I have a starting point Tree Query generated for me that I can mess around with to get what I need.

I did this as normal on Visual Studio Team Services (formerly Visual Studio Online or VSO) the other day and to my horror, my generated query didn’t show the hierarchy I was looking at in my backlog view meaning that I actually had to think about it for the first time in a while!

In VSTS/TFS 2015, the backlog view has changed a little and now the Parent/Child view is either On or Off.

The create query button is still there and it generates a tree query but it only shows Product Backlog Items or Bugs with any nested items the have (which I don’t encourage you to do, keep that backlog flat as you can’t reprioritise nested items independently).

So I had to generate my own starting query.

In this instance I just wanted EVERYTHING, but in a hierarchical view so I started here:

What this tree query is doing is to match the top level clause first (Any work item) and then match any child items which meet the criteria (Any work item) which in this case showed Epics – Tasks, ignoring any state or other criteria such as Area or Iteration Paths.

So what changed?

If I look at the generated query from TFS 2013 we can see what it is doing (and understand why TFS 2015 doesn’t work that way anymore)

Remember this query was looking at Features and then any linked Features, Bugs, PBIs or Tasks.  Any PBI not rolling up to a Feature would not appear in the results.  Also, importantly the query is sorted by Backlog Priority followed by ID.

If we look at an alternative view which is Backlog Items to Features, what it will show is my entire backlog of PBIs/Bugs and any parent Features.  Any Features that do not have child Requirements will not show up in the results.

The difference here is that we are comparing the linked Work Items first (any PBIs/Bugs meeting the criteria) and then looking for any parent items that they have that are either more requirements or Features.

How do I reproduce it in VSTS?

In TFS 2015/VSTS the generated query I initially expected is probably closer to my Any Item linked to Any Item query, just with a few restrictions.  For instance my top level query might look something like this if I want to see Features, Bugs, PBIs and Tasks and any Children they have.

Think carefully about what you want to see at the top level.  Maybe you only want to see Features (or Epics or whatever) and the tree below them – and then have a separate query for any orphaned PBIs, Bug or Tasks.  There are lots of edge cases such as a PBI in an active state but its parent is closed so make sure you’re not losing things.

Good queries are really only useful against a well organized backlog.  If you need help to organise your backlog and really understand how your project is doing then get in touch with RippleRock.

Cheers,

Richard