I’m in the process of migrating our TFS Instances to 2013. During my research I’d seen demos with the “Features” feature. In TFS 2013, there is now a Work Item Type named Feature which is meant to be a parent to several Product Backlog Items. I was able to easily create features but I also knew there is supposed to be a Features Backlog. On my TFS cloud instance it works fine but there was no sign of the Features backlog on the web interface for my On Premise instance of TFS 2013. The screenshot shows what I was hoping to find. Continue below to find out how to enable it.

image

It turns out that getting this to show up was really quite simple but not exactly intuitive. Features needs to be enabled as part of the Access Levels portion of TFS.

On the top right side of the TFS web app, click the “gear” to go to the control panel.

image

You may see this menu. If not, skip the next step! If you do, just click the Control Panel link to go to the main control panel page.

image

Hopefully you will see a menu like this:

image

From here, click on “Access Levels” and you’ll see something like this:

image

 

You will see that there are 3 choices for access levels. We’ve got “Standard” set as the default. I’m not positive we’ll keep it this way and every team should decide for themselves what they want to do about the default. However, you must have “Full” Access to see the “Features” backlog. So add some users to that level or set it as the default. Once you do, users with Full Access will see the Features Backlog (similar to the first screenshot in this post).

I’m not exactly sure why the access levels are set up like this. I’m new to TFS2013 so it may be possible to set this visibility in other ways. But it seems odd that enabling the Features backlog is tied to other features like “Team Rooms” and “Test Case Management”. Those are great features but I am not sure why they are all lumped together.

I recently found out the hard way that the underscore character “_” can be problematic within URLs, particularly with Internet Explorer. Here is why…

(FYI, my testing was done with IE 9)

First of all, the underscore character is a perfectly acceptable character in a URL. Web browsers can deal with it fine in most circumstances. However, IE seems to dislike the underscore when it is in a domain or subdomain name, for instance www.my_site.com or test_site.mysite.com. Will it work? Under general circumstances it might. The problem shows up when you need a cookie for the site, which most sites do, especially if you are using cookies as part of your authentication scheme. IE can’t create cookies when the domain or subdomain name has an underscore.

This doesn’t seem to be a problem for Firefox (I’ve tried it) and Chrome (so I have heard).

A note about SEO

Also, it is worth mentioning that the underscore is not a good choice in a URL if you are interested in SEO. That’s because some search engines like Google don’t consider the underscore a word separator. To Google, it reads a URL like “mysite.com/Page_About_Something_Cool” as mysite.com/pageaboutsomethingcool” which won’t help your rankings much. Bing is fine with the underscore but of course simply using a dash “-“ instead will keep both search engines happy.

I’ll close with a few examples

www.somesite.com/page-with-content good choice for a variety of browsers and search engines
mysubdomain.somesite.com/page-with-content good choice for a variety of browsers and search engines
www.some_site.com trouble for IE with cookies
sub_domain.somesite.com trouble for IE with cookies
www.somesite.com/page_with_content valid but bad for SEO with Google
Posted in Web.