Hosted Build Servers up to date with Windows 8.1

One of the reasons for using Team Foundation Service and others hosted services is not worrying about technology updates as they are carried on by the provider.

Team Foundation Service is no exception and today, together with the Preview’s release of Visual Studio 2013 and Windows 8.1, the Hosted Build Server got upgraded to Windows 8.1 as well!

But, but. You won’t be able to select them in Visual Studio as a beginning. You have to browse to your Team Foundation Service instance, and enable them for the required project:

Just after doing that you’d be able to select the required Build Controller:

and in the Build Definition itself:

Man forewarned is forearmed :)

Example on what Agile Portfolio Management is covering

I have been asked about a quick example, so let’s take this screenshot:

This is something you can achieve today via Project. But it is not feasible in Team Foundation Server 2012 stating that the “As a customer…” are User Stories. You must use the Project Server integration, setting Project Server and the integration up, it is an expensive process and it is not suitable for everybody.

Here’s why I feel the Agile Portfolio Management is very useful. I understand Project Server is not for everybody, and this new features enable scenarios which were an exclusive of Project Server in the past.

Of course Project Server is not going away, but at least now if you have a well defined scenario you can choose which tool to use.

Basics of Agile Portfolio Management: Themes and Epics

Apart from the technology itself, the introduction of the Agile Portfolio Management in Team Foundation Server and Service has a huge impact on the surface you can cover on your project.

Beware: in most of the cases, I am talking about mid-sized to big projects. Introducing a concept like this in small projects could be counterproductive.

As far as now, the most common way of tackling agile product management is to create some User Stories and then split them into tasks. This is perfectly fine and it is not changing, but sometimes you can face the following problem: the User Story is too big for being delivered in a sprint.

Unfortunately it happens. So to solve this, you have to use the Epic concept.

An Epic is basically a very big User Story, which is split into several sub-Stories whose effort is compatible with the Sprint duration. Think about it as a goal. An Epic contains one or more User Stories, kept together by a common topic. You won’t deliver an Epic in one sprint, usually an Epic is a big part of the product, a (marketable) feature. You manage this on top of the product, as it can impact other products in your organization.

The Theme is on top of everything. Talking in terms of a project, it can be a major release. It is an initiative, one of the cornerstones of the project itself. Themes drive the strategy, and they express a direction – they are generally not too specific because of it.

At the moment in Team Foundation Service (and soon in Team Foundation Server 2013) you’d get the Epic concept out-of-the-box. But as Brian Harry told us in his post, it is possible to customize the experience with a low effort.

A huge leap toward the Agile Portfolio Management

Up to yesterday, managing something more than User Stories and Tasks, Bugs, etc. required a certain degree of abstraction and usage of specific tools like Project Server.

With the newly revealed Agile Portfolio Management feature now we can avoid to use Project Server for doing something which is not designed for, thus we can still integrated it (with TFS 2013) as needed.

Let’s take this example: we want to create a certain system, and one of its features is the Trash Bin. So we create a feature, and I can see it by filtering the Backlog by Features:

 

This feature has some user stories into it. Let’s say we want to put stuff into the bin and that we want to empty the bin as needed.

These are Product Backlog Items, or Requirements depending on the Process Template you are using. I am using CMMI, so they are requirements – and I change the filter again:

Of course these Requirements are split onto several different tasks, and this is not different since the past. Changing the filter again this is what I see:

This view is exactly what we wanted to achieve. And of course it is way easier to understand and visualize, than using other tools – often not designed for fitting that specific need.

Let’s spread this concept quite a little: can it be handy if you have multiple Scrum teams working on the same backlog? If you have different backlogs (you shouldn’t…) for different teams, why not merging everything on the same backlog in this way? It was hard to explain to some manager how the project was going in term of features and market comparison. Now it isn’t, because you can use the Feature work item type as an abstraction on the work the teams are doing. And it is out-of-the-box, which is never bad.

As Brian said, it is just the beginning…there is surely more to add here.

Team Rooms in Team Foundation Service

So now after the Tech.Ed announcement the Team Rooms are available :)

They are not just a chit-chat tool for conversations into the team. They are an invaluable tool for collaboration.

First of all, we can configure it as a broadcast messenger for certain events

It is possible to tag a certain User Story, or a specific build to talk about.

But the best comes to the specific collaboration tags: @ and #.

The @ tag is for tagging a user:

which is going to get notified about it.

The # tag is for mentioning a specific work item:

After clicking on the hyperlink a new tab is going to be opened with the required work item.

All of this could seem pretty silly, but I can ensure they add some value to the team work, less overwhelmed by emails and better communicating among the members.