VSTS Product Backlog Hierarchy

Documents the VSTS Product Backlog Hierarchy used for sophisticated products and portfolios of products, and how you can use the levels of the hierarchy and the work item types.

Written in 2016-2017:
This is part of a series of articles that I originally wrote in 2016-2017 and were only published on private internal company wikis. I am publishing them publicly for the first time in 2019, here on my blog.

Written for Microsoft’s VSTS:
Some content is written for Microsoft’s Visual Studio Team Services (VSTS), as it existed in 2016-2017. VSTS was renamed to Azure DevOps in 2018 (

Learn More:

VSTS Product Backlog Hierarchy:

This documents how we are using the VSTS work item hierarchy to provide the product backlog structure needed to align it to product strategy and organize and manage a sophisticated product development effort.

Since VSTS only supports a 4 level work item hierarchy, and sophisticated product requires 6 or more, we had to workaround this VSTS limitation by using nested work items.  Specifically nesting the Epic level work item types to simulate the 2 additional levels needed – the Initiative level and the Theme level. 

NOTE:  The color coding below matches the colors used in VSTS.

Level                         Purpose & Notes

Product Managers are the Primary Responsible Person (PRP) for Initiative down to Epic levels (below) of the Backlog, in extensive collaborate with Product Owners and Scrum team.

1.    Initiative                     
  • Group Epics in to a 1st level.
2.     > Theme                
  • Group Epics in to a 2nd level.
3.         > Epic            
  • Captures a very specific, small and clear customer value deliverable.
  • Should use a user narrative statement, for example As a…  I want to…  So that… 
  • Have detailed requirements in Description.
  • Have detailed Acceptance Criteria that can be used to determine if it has been delivered.

Scrum Product Owners are the Primary Responsible Person (PRP) for Feature level (below) of the Backlog, in extensive collaborate with Product Managers and Scrum team.

See Scrum Roles & Responsibilities to learn more.

4.             > Feature        
  • User centric or engineering centric (such as architecture, foundational, common components, etc.).
  • Goal is to complete Feature in a single Program Increment (PI) / Release.
    • Meaning it can be started and completed (Closed) within a single Program Increment (PI) / Release.
    • However, if it cannot be closed in a single Program Increment (PI), it can be slipped to the next PI, but no more than 1 more PI.  This should be an edge case, and not a common occurrence.  If this happens with more than 10% of the time, then the team must break down Features into smaller sizes to prevent this.
    • Program Increment (PI) / Release is defined by Release Version field in the work item.
  • Are Scrum team specific, by using Area Path to “assign” it to a team.
  • Can span multiple Sprints.
  • High level work effort estimates measured in level of effort, using Points. 
                          Scrum team members are the Primary Responsible Persons (PRP) for Work Story, Bug & Task levels (below) of the Backlog.
5.                 >

Work Story
(VSTS Work Item

Type = User Story or Product


Item – PBI)

  • 1 Person’s Worth of Effort, 1/2 Sprint, 1 Story 
    Should be small enough to be completed by 1 person’s worth of effort in 1/2 Sprint (does not mean a single person must work on the Story).
    • 1 Person’s worth of effort for 1/2 of a Sprint = 5 person days (in a 2 week Sprint).
    • Can be no larger than 1 person’s effort, 1 Sprint.  
    • 1 person effort means the total work effort equal to 1 person.  Not that a single person does all the work in the Story.  Multiple people can work on 1 Story – that is managed by breaking the work down in to Tasks assigned to different people.
    • Ideal goal is to break Story down into even smaller pieces.
    • See Writing & Breaking Down Tips for Features, Epics, Stories, Etc. in section on INVEST > Small & in Learn More > INVEST.
  • Used by Scrum teams to plan any type of work in to Sprints.
  • Work effort estimates measured in Story Points.
  • Type field is optional, to identify the type of work or skill set required to assist in work load planning in Sprints.  Examples: Action Item, Dev, Doc, Multiple, Ops, QA, Product Management, Release Eng, etc.
6.                        Task
  • Task breakdown of Work Stories.
  • Work effort measured in person hours.
5.                 > Bug    
  • Bugs, Defects, Customer Issues, Etc.
6.                        Task
  • Same as Task above.

Out Of The Box VSTS Backlog Hierarchy:

This documents the out of the box VSTS Backlog work item hierarchy.

About VSTS Limitation:

VSTS is currently limited to a 4 level native hierarchy and it is not extensible.  Microsoft has indicated to us that they would like to enhance VSTS to allow customers to extend and configure the work item hierarchy and more configurability over work item types, but they have not made that official nor provided a target date for these feature enhancements.

Microsoft VSTS Docs:

Links to Microsoft documentation related to this subject area.

At A Glance – VSTS Backlog Work Item Hierarchy:

Here’s what the out of the box VSTS work item hierarchy looks like today in the current available version of VSTS (as of Dec 14, 2016).

Level                 Purpose & Notes
1. > Epic            
  • Group Features together.
2.     > Feature          
3.         > User Story    
  • Used by Scrum teams to plan work in to Sprints.
  • Work effort estimates measured in Story Points.
4.                Task
  • Task breakdown of Work Stories.
  • Work effort measured in person hours.
3.         > Bug    
  • Bugs, Defects, Customer Issues, Etc.
4.                Task
  • Same as Task above.

3 thoughts on “VSTS Product Backlog Hierarchy”

Leave a Reply

%d bloggers like this: