Visual Studio Team Services Primer

What is VSTS and why should I care?

Warning, Visual Studio Team Services is coming and consulting best practices are changing. VSTS is a cool suite of tools for Agile Development and Project Management by Microsoft.  Officially, this is what Microsoft says VSTS is: 

*https://docs.microsoft.com/en-us/vsts/user-guide/what-is-vsts

The two tools that we’re most interested to adopt first are:

  • Git repositories for source control
  • Agile tools to support planning and tracking work

What’s Git and why is it important?

Hopefully, you’re a modern-day developer who at least knows what source control is. For anyone else, who need an introduction Atlassian has a pretty good primer here. Git is a source code repository where the code is saved, versioned, and backed up; similar to a Google Doc, SharePoint, or Dropbox. In the event of a catastrophe, the code can be retrieved.

Most days, things go according to plan. Sense Corp has really talented Scorpions, but the occasional all-nighter or the pressures of a looming deadline and incidents are bound to happen. Implementing source control provides insurance against having a bad day. It gives us the superpower to turn back time and undo costly mistakes.

Historically at Sense Corp, source control is a practice that most of our projects have not implemented or actively used. Superpower aside, we generate a lot of valuable experiences that are represented as code. Having this repository of knowledge will continue to provide a valuable reference for projects to come. And frankly, this is a base skill to software development & consulting that our developers should know, and a practice our PM’s should encourage.

Okay, cool, I get it, we can do better and with VSTS we will. What else can it do besides save some files and turn back time? 

They say it takes two to tango, and Agile tools will be Source Controls plus one. To give an analogy, VSTS is like Jira but for Microsoft. Saving source code is only half the battle; planning work and organizing tasks are just as important.

Some of the cool widgets in VSTS include various work items like Features, User Stories, and Tasks as well as three different backlogs and two different boards for tracking work via Kanban. Having various scopes via these boards provides Management, Project Owners, and Stakeholders insight and overview at a high level but more importantly, keep’s them out of the day-to-day work the developers are doing.

Other widgets include customizable dashboards, unlimited personalized reports and queries, and the ability to predict the future. These concepts and more will be explored in a future multipart series.

  • Epics vs Features
  • User Story & Task Deep Dive
  • User Stories & Sprints: Understanding Capacity
  • Story Points vs Estimation (hours)
  • Charts: Cumulative Flow, Velocity, Forecasting, & Burndown
  • Project Dashboard vs Personal Dashboard
  • Custom Work Items

VSTS: Users Stories and Tasks

Getting Started

This is the second of a multipart series. In this article, we will be diving into User Stories and Task and comparing various features and explaining when and how to use them. We started the conversation in the first article about Epics, Features, and presented several ideas on how they can be used on a project. User Stories and Tasks are the natural next steps.

Also, if you missed the first article, you can read it here.

User Stories and Task Deep Dive

To reiterate a point from our last article. There are six main work item types. Epics & Features are scoped to provide senior leadership and product owners with a high-level overview and even have their own portfolio backlog. User Stories and Tasks are scoped to provide project managers, developers, business analysists, and testers with a lower level overview. Issue’s and Bugs round out the last two but will be covered in another article.

“User Stories define the applications, requirements, and elements that teams need to create. Product owners typically define and stack rank user stories. The team then estimates the effort and work to deliver the highest priority items.” – Microsoft

From this perspective, we begin to see why having additional work item types are important and how this architecture allows for a project to appropriately group work. One of the biggest frustrations encountered on a project is a client’s senior leadership mucking around with daily task management rather than delegating and trusting the team.

The Task work item provides the lowest level of granularity. “Tasks can represent different work to be performed – such as design, code, test, content, sign off.” – Microsoft

Similar to Epics, it’s entirely possible to develop code without Tasks. However, by skipping Task creation the development team misses out on an opportunity to utilize a robust set of planning and estimation tools; this practice is not recommended.

Deconstructing a User Story

Below is a graphic that we will use to explain the various aspects of a User Story and highlight recommended practices. Take a few minutes to review the graphic.

The only required field on a User Story is the Title. Every other field is optional but recommended.

  • Description: should be populated with enough detail for a member of the team to be able to estimate the level of effort to implement the User Story
  • Acceptance Criteria: clearly state the criteria to which the User Story can be marked as complete
  •  Classification or Value Area:  allows for grouping by either Architectural or Business
  • Story Points: way of estimating the amount of work required to complete the story but is not a direct correlation of hours;
    • rather it represents a bucket of hours per point.
  • Priority: the importance of this feature:
    • required to ship, required to ship but address later, or optionally based on resources, time, and risk.
  •  Risk: a subjective range describing the uncertainty of completing the User Story.

Decomposing a Task

Below is another graphic that we will use to explain the various aspects of a Task and highlight recommended practices. Take a few minutes to review the graphic.

Similar to a User Story, only the title is required. 

  • Description: should be populated with enough detail for a member of the team to be able to estimate the Effort to implement the Task
  • Priority: the importance of this task:
    • required to ship, required to ship but address later, or optionally based on resources, time, and risk.
  •  Effort (Hours)
    • Original Estimate: the amount of work required to complete a task. This field does not change after assigned.
    • Remaining Work: the amount of work remaining to complete the task. Update this field as work progresses. 
    • Completed Work: the amount of time spent on a task. 
  • Activity:  the type of activity this task represents when estimating sprint capacity by activity.

VSTS: Epics vs Features

Getting started

Welcome to the first of a multipart series discussing various aspects of Visual Studio Team Services. If you haven’t yet, check out the great resources the Digital team have been curating in the learning community and elsewhere. I recommend checking out the additional links at the bottom of the article.

Diving into Epics, Features, and User Stories. It’s important to know there are six types of work items. Epics, Features, and User Stories are the three main types of tasks being the fourth most common. Issues and Bugs (also known as a defect) round out the last two.

Including items under Test adds an additional five work items. However, the Test module is not included in the base subscription and requires a license to access the suite of tools.

All of the work items are listed out in the picture above. What’s interesting is the division of work items into various groups: Portfolio Backlog, Product Backlog, and Issue Tracking. For this conversation, we are going to focus on the Portfolio Backlog.

What are Epics, Features, & User Stories

Epics are large, overarching goals or ideas that take a significant effort to complete and often span multiple sprints. On previous projects, Epics might have been named after phases and probably broken into timeframes of eight to twelve weeks each. 

Features are a work item that is smaller than Epics but also larger than a User Story (pretty insightful, right).  Features should be created first and can be found by referencing a project plan, BRD, or TDD document as they tend to be top-level items.

User Stories define the application, requirements, and elements that teams need to develop. User Stories are the first level of documentation that developers interact with. Each User Story allows the capture of detailed information.

These descriptions of Epics, Features, and User Stories are pretty stark and haven’t really answered what they are. The main concept you should have taken away from the descriptions is that Epics and Features provide a generic way to group or bucket work. Based on your project you might not even need Epics and only a handful of Features. A better explanation would be to quote Drew Carey, “Welcome to Whose line is it anyway. Where everything’s made up and the points don’t matter”. 

  • Epics, Features, and User Stories are conceptual buckets that allow for work to be organized at various levels of management. Not all projects even need Epics; by default, they are turned off.

When to use Epics & Features

The hardest part of understanding “when”, is getting used to the artistic side of Agile or Scrum planning. When googling “what’s an Epic”, “what a Feature”, and “Epic vs Feature” a lot of material on Microsoft recommends using the tool as it makes sense to you. The answer sounds a lot like the Socratic method of answering a question with another question. Most of the examples I found were in demo videos showing how Company X was using the product.

In the case of Microsoft, they actually gave a timeline of about how big each bucket should be.

Work ItemParadigmTimeframeOwnership
Epics
Scenarios18 MonthsLeadership Team
FeaturesSeasons6 MonthsLeadership TeamDev Team
User Stories
Plans3 SprintsDev Team
Tasks
Sprints3 WeeksDev Team
  • After two sprints or six weeks, the team would plan the next three sprints.
  • Once a quarter they would plan the next six months.
  • And every six months they would plan the next eighteen months.
  • Each Feature was assigned to one team.
  • Every team was made up of four smaller micro-teams, each conducting daily scrums.
  • The team as a whole meets every two sprints to share goals and highlight resource dependencies.

The conclusion is that each division is aligned with the overall goals of the company. Various levels of leadership from VP’s and Directors down to Managers and Team Leads all have the right scope at which to plan.

TLDR: Use Epics when trying to bucket multiple streams of work or have more than one team on a client engagement. The analogy is similar to a car.

  • Epic = Manufacture
  • Feature = Model
  • User Stories = Functions of the car
  • Tasks = Parts to install
  • Bug = Product Recall