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