Azure DevOps, Scrum, & .NET Software Leadership and Consulting Services

Free course! Predicting the Future, Estimating, and Running Your Projects with Flow Metrics

ALM with TFS 2012 Fundamentals at

My first online course for Pluralsight went live a few days ago.  Application Lifecycle Management (ALM) with Team Foundation Server 2012 (TFS2012) Fundamentals.  This is a first course in a multi-course series so keep your eyes open for more ALM courses in the near future!


Here’s the course description:

Team Foundation Server (TFS) is more than just version control! This course provides an overview of the Application Lifecycle Management (ALM) tooling that’s available using Team Foundation Server 2012. We’ll start with version control and move on to cover TFS builds, project planning and project management using TFS Work Items. Along the way, we’ll also discuss the features of TFS Source Control including branching and merging and also how to customize TFS’s work items and automated build features.

Here is the course outline:

  • Overview
    • TFS is more than just version control: The 40,000 foot overview of Microsoft ALM
    • If you only learn one thing…
    • What is ALM?
    • TFS can help
    • TFS and ALM…not just for small teams
    • The Big Picture and TFS
    • Team Foundation Server
    • Connect to TFS
    • Version Control
    • Requirement Management
    • Agile Planning
    • Automated Build
    • Testing and Defect Tracking
    • Feedback
    • Lab Management
    • Reporting
  • Basic Setup & Configuration
    • The core pieces of TFS
    • The other pieces of TFS
    • Things that bolt on to TFS
    • TFS configurations
    • TFS on Windows Azure
    • Fancy TFS configurations
    • TFS hardware capacity planning
    • TFS pre-requisites
    • Installing TFS
    • Team Project vs. Team Project Collections
    • Process Templates
    • Demo: Create a Team Project
    • Permissions and Security
    • Demo: Tour of TFS permissions
    • Demo: The TFS Administration Console
    • A simple backup plan
  • Version Control Basics
    • TFS Version Control (aka. TFS Source Control)
    • How to access TFS Version Control
    • Demo: My First ‘Get Latest’
    • TFS Workspaces
    • Demo: The TFS Workspace Editor
    • Server vs. Local Workspaces
    • Configure a new TFS project
    • Demo: Set up the repository and add code
    • Keep it simple.
    • Version control operations
  • Version Control Beyond The Basics
    • Demo: Offline source control features
    • Free yourself from the real-only bit
    • Demo: Detected changes and associated work items
    • Version control locks
    • Shelving
    • Demo: Shelving
    • Branching and Merging
    • Demo: Server-side settings
    • Demo: Permissions
  • Work Item Basics
    • What is a work item?
    • Ways to edit a work item
    • Demo: Edit Work Items in Visual Studio 2012
    • Demo: Edit Work Items in Excel
    • Work Item Types
    • Work Item Links
    • Demo: Work Item Links
    • Stay organized with Areas & Iterations
    • Demo: Areas & Iterations
    • Work Item Queries
    • Demo: Work Item Queries
  • Agile & Scrum Planning Tools
    • Subdivide your project with Teams
    • Demo: Create a TFS Team
    • Some context about Work Items
    • The blindingly fast overview of Scrum and Agile
    • The Scrum / Agile Planning Tools in TFS2012
    • Demo: Product Backlog Manager
    • Demo: Sprint Planning
    • Demo: The Scrum Board & Running the Daily Standup
    • Demo: The Burndown Chart
  • Work Item Customization
    • Work Item Customization
    • WitAdmin.exe
    • Backup your process template
    • Demo: Backup your process template
    • Two ways to customize
    • Structure of a Work Item Type Definition (WITD)
    • Work Item Fields
    • Work Item States and Transitions
    • Work Item Form
    • Demo: Customize the WITD
    • Demo: Upload the changes to TFS
    • Demo: Add the customization to Source Control
  • Automated Build Basics
    • Why automated builds?
    • Installing and Planning TFS Build
    • Demo: Install the TFS build service
    • Demo: Create a build definition
    • Demo: Run the build
  • Automated Build Beyond The Basics
    • Demo: Gated Check-in Builds
    • Build customization
    • Demo: Clone the default build
    • Demo: Add the build to the build editor project
    • Demo: Using 3rd party build activities
    • Demo: Add an argument to the build script

Here’s the link to that course again on Pluralsight’s website.



Looking for an in-person version of this course?  We’re happy to come to you.  Want help upgrading to TFS2012?  Need guidance for how to adopt TFS and Microsoft Test Manager (MTM)?  Trying to streamline Scrum using TFS?  Drop us a line at


3 responses to “ALM with TFS 2012 Fundamentals at”

  1. […] ALM with TFS 2012 Fundamentals at – My good friend Ben Day has created his first online course for Pluralsight.  I haven’t watched it yet, but Ben is an incredible speaker, so I’m sure it will be great. […]

  2. Riz Avatar

    Hi Benjamin,

    I’m going through the TFS course and I’ve finished the version control basics and beyond the basics. I’m trying to put a folder structure in place at work and I’m wondering how I would go about structuring shared libraries.

    So for example, I have a Component Art library which is a .csproj by itself and includes all the source code. This is shared by projects A and B. Would I create a separate Team Project for Component Art and then branch it to Project A as well as B? I’m just a bit confused as to how I can go about accomplishing this.

    Thanks in advance for any insight you might have.

    1. Ben Day Avatar

      Hi Riz,

      I’d suggest putting the Component One code in a completely separate Team Project and then doing “releases” out of that project. What is mean is that, for the sake of organization, you’ll do all the compilations for Component One in that separate space and then that Team Project will issue binaries (*.dll’s, etc) that you will then add to your the other Team Projects that use those components. So, in your other Team Projects, you’ll probably have a folder in source control called “Binaries” and you’ll put the released DLLs from the Component One Team Project into that directory. Doing it this way give you room to accept changes from the Component One project as you see fit.

      Does that make sense?


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.