As you know, in one of the latest Team Foundation Service deployments (I recall it, the team works on a three-weeks-long sprint) and soon to be in the Quarterly Update 1 for Team Foundation Server, there has been a nice new feature: the Kanban Board.
Kanban is a process based on the boundaries imposed by the work-in-progress limits. Everything is in a queue, with defined states (eg. Development Ready, Test Ready, Release Ready, etc.), and the to-do jobs are governed by the capacity of the team. Ideally, this is the best way for ‘just in time’ production
It has a fairly interesting history, as it’s been created by a Japanese man watching american stocking habits in supermarkets. More on Wikipedia.
Kanban forces the team to rely on their self-control, continuously adjusting their queue based on the work they can do. Using it together with Scrum – for instance, inside the sprints – makes software development like a Swiss clock. That is my opinion, of course 
How does that fit in Team Foundation Service? The Kanban Board is the main tool for adopting Kanban: it’s visual, and effective.
In our case, it doesn’t affect the existing Backlog Board, they are complementary! Here’s what I mean:
This is a sample Backlog Board: I can see on the left my PBIs, with the inner tasks composing it, and their status.
Here is the correspondent Kanban Board on the same project:
I can just see the User Stories, and not the linked Work Items. And as I am the only project member, I entered 1 as the maximum WIP load. So I can understand just looking at it that I am overcommitted.
So the Backlog Board can be used to understand a finer grain load, at a task level, for my team. The Kanban Board is a useful tool for a project level inspection. They are two different tool but they might be used together