Hello All, over the past year I've been working with a lot of teams on agile transformations, and it seems to be something that dominates most of the conversations I have. So I wanted to document a lot of recommendations I have to help teams that are trying to become Agile to leverage the tools in TFS and VSTS to do so.

So given that, I think a great place to start is the "Work" tab in VSTS. This holds a lot of questions from teams and groups that I talk to, as they want to document how they do work, and they LOVE the addition of the "Related Check-in", and the promise of connecting the code changes they check in with the originating requirement. So Given that. Let's talk about the templates, and then dive into the different work item types.

So out-of-the-box, VSTS supports the following types of projects

  • Scrum - This template is meant to follow the scrum methodology as if it were religious doctrine. Which is great if your teams are meant to function that way. But for many teams this can cause problems as they want to follow a "scrum-like" philosophy.
  • CMMI - This is your traditional waterfall model, which functions very much like you would expect with lots of fields to accommodate a variety of different states and approvals along the way.
  • Agile - This is sort of a "one-size-fits-all" approach to Agile, and is built to work with a variety of agile practices. This is attractive to a lot of teams for that very reason. It's like a minimalist approach to agile that provides a foundation to be built upon.

For the purpose of these posts, I will be focusing on the "Agile" template, and in that template are the following levels of work items.

Work Item Levels for Agile

Now one thing to keep in mind as we go through this, is that I've always been told, TFS / VSTS are not PROJECT Management Tools, they are PRODUCT Management tools. And that means that they are meant to live the entire lifetime of the product, well beyond the Project's lifecycle.

Below is a description of each of the work items shown above. I will be going into greater depth on these in future posts.

  • Epic - These are your large scale goals and initiatives. These are major organizational goals or product goals.
  • Feature - These are any piece of work that requires more than one sprint to complete. If your sprint length is 2 weeks, then this is anything that takes 15 days+.
  • User Story - These are work items designed to be completed within the sprint. The intention is that this is the lowest level that a developer will focus their attention on to be productive.
  • Task - These are the developer tasks to make the above item a reality. This is when we start capturing details about the technical implementation.

Now, one item worth mentioning is that you do not have to use all work items on all projects and can actually turn them off by doing the following steps

  • Open VSTS in the browser and go to the work tab. Select any work item backlog (in the example, User Stories is selected). Go to work tab

  • Click on the "Gear" for settings

Go to settings * Go to "Backlogs" Select Backlogs * Uncheck the work item backlogs you don't want to see. Select backlogs to see / unsee

In my experience the best way to approach using these work item is to look at the work your trying to track and let it evolve organically. And what I mean by that is start at the bottom and work your way up, start with User Stories / Tasks, and when you see the need to start tracking features, deal in features. Not all projects will need all types.

That's it for this post, next time we will talk about the basics of work items.