Visual Studio Online (VSO) and it’s on-premise counterpart Team Foundation Server (TFS) are great tools for managing work and collaborating with a team. For many projects getting started is as easy as choosing a work template and version control. For others we need to build a more robust foundation on which we will orchestrate work in a multi-team environment.
In this series I intend to:
- Introduce organizational components
- Manipulate these structural pieces to form a shared environment
- Discuss ways different teams can work in the same environment but have their own workflow
– Part 1: Introduction and Setup
– Part 2: Efficient Work Tracking (coming soon)
– Part 3: Supporting Your Manager’s Needs (coming soon)
VSO landing page
Project – the top level organizational component of VSO
Note: We will start by creating a VSO Project but first let’s disassociate the word project with this organizational component. I’ve found when setting up any complex structure in VSO there is nothing that will be more confusing than this little bit of naming. Really beyond a single team – single product configuration the word project, especially in an environment where we already use the word for everything from managers to features, loses meaning. I will attempt to only use project in this post when referring to the actual VSO project and product when discussing deliverables.
Let’s get started and create a new project!
Notice that we are selecting the Scrum template for our process and Git as our version control. I would recommend doing your due diligence before selecting either. These are possibly the two most important decisions we will have to make when deciding to configure our environment for multiple teams. The process template and version control we choose will be utilized across all of the teams under our project.
Your teams are going to absolutely love this!
From here we’ll navigate to our project and check out some of the defaults and introduce the next three components of organization.
On project creation VSO will give you some prompts for where to start. Below is the main backlog page. Work entered here, through Visual Studio, or a 3rd party tool should be available to manage from this screen as long as we have the right pieces in place. For now notice that this is the backlog for the “Blog Project” team which isn’t very useful to us yet.
Team – comprised of one or more people of varying roles (developers, QA, stakeholders, managers). The Team component of our structure is the glue that binds all of our pieces together; it’s where we will define our responsible Areas, set up Iterations, and use various built in tools to track and schedule work. Teams may nest inside other teams which can be useful to create structures where smaller Teams can work towards central goals or allow managers to roll information into a centralized view.
Our Team structure follows this pattern where managers have created groupings of Teams that roll up into a view they can report on.
Below we see this being set up; each team has a description of what it is and how they work. How they work is important to note because each Team does things a bit differently which is seamless even within a single Project.
Note: we have unchecked the box to create an Area path with each team. Generally you will leave this checked for simple set ups but in our case we have more complex needs
Our teams all want to be in control of the way they work and will utilize VSO’s various tools to accomplish their goals.
Note: credit to J. K. Rowling for my team names and hopefully this falls under fair use
Hufflepuff – Agile team who hates the overhead of planning sprints, they will utilize a Kanban board and continuous delivery to accomplish their goals.
Ravenclaw – Team who is bound by their billing model which forces them to estimate features down to the hour. They plan product releases on a quarterly schedule but deliver completed work to themselves in sprints in order to keep their own sanity.
Gryffindor – Scrum team who shares products (and a product owner) with Slytherin. They use a combination of branching and feature flags to align shared work which is coordinated through regular cross-team communication.
Slytherin – Scrum team who shares products (and a product owner) with Gryffindor. They use a combination of branching and feature flags to align shared work which is coordinated through regular cross-team communication.
Area – a level of granularity that defines, is within, or spans products that allows us to group work. Areas will be assigned to teams and will act as a filter for the work that team can view. Multiple areas may be assigned to any given Team.
Below is a before and after of the Area set up for our environment. Our Areas are set up mostly as individual products but can be nested to a configuration with a finer grain definition.
Iteration – a flexible container of work usually used to keep work together for a release or time-boxed cycle. Iterations in VSO are configured in a nested structure similar to folders. Each team must have a selected iteration as their “Backlog Iteration” and only the iterations under that path will be visible to that team. An important distinction when thinking about Areas and Iterations is that while work items may be assigned an area they really belong to an iteration.
In our examples we will be treating iterations as time-boxed objects on a regular cycle (Sprints) for all except one of our teams.
As you’ll see below I’ve created a series of hierarchical iterations with the focus centered around having work assigned under a group then a team then a particular sprint. We’ll see in part 2 how we can use queries and the TFS team home page to get great at a glace info for how your team is doing and what work is being done.
Note: One of the most important things to take away from the below structure (even if you’re just one single team) is adding Completed, Current, and Future sub-iterations below your team’s backlog. We do this primarily for work query maintenance; it’s much more efficient to have multiple queries looking for iterations under a higher level and then manage moving iterations in and out of groupings than to edit multiple queries every time a sprint has been completed.