Scrum meets the pool – swimlanes in VSO’s backlog board

With the update of June 3rd VSO got a new and very useful feature in the Backlog Board: swimlanes.

What does that mean? It means you can have this situation:

This allows for an even finer time and resources management, for example. It mostly impacts prioritisation, something that happens with critical bugs stopping a production system. Keep in mind that a swimlane configured as above should be used very sparingly.

It could be even more creative:

You might be selling a product which, from time to time, has customer’s personalisations, which you need to schedule with the product itself. This is another way of using the swimlanes.

It is a tool which increases the flexibility a lot – but remember that it is just an aid, it doesn’t work as a given. Your process must be already resilient to this, and the tools is only there to help.

Beware of the Package Location in VSRM!

I am working on a few scenarios using VSRM and DSC, and something funny happened. Picking a build up for release, I noticed this:

Localhost? I am pretty sure I didn’t enter localhost anywhere in VSRM!

And I was right – there was no localhost to be found in my pipeline configuration. But this just caused problems deploying to a different workgroup target server, due to the lack of a proper DNS infrastructure.

The culprit here is the XAML Build I was using, its Drop Location was configured with \\localhost because it is an AIO demo box, and as there is no such name resolution facility VSRM cannot access my source server from the target.

To fix this you’d just need to change the Drop Location of the build.

A note on reusing your custom fields

When you customise your Work Item Types you often start with a lone custom Field, and then you forget about it for a while.

But what happens when you need to add the same field to another WIT? The first thing you are naturally inclined to do is to add a new one, with the same name and reporting design but with a different Reference Name (because maybe you attended one of my sessions on TFS Administration and you then discover you should mark your custom Reference Names in a significant matter :-) ).

The result?

How can I reuse my existing field then? The easiest way is to create the custom Field in the second Work Item Type with exactly the same properties, including the Reference Name. So TFS will correctly use the same Field and your experience is going to be consistent.