VSTS Product Backlog Hierarchy

By
Ken Adams

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.

December 21, 2016

Categories: Agile, Engineering, Jira/Azure DevOps/VSTS
Tags: Agile, Azure DevOps/VSTS, Scrum

Contents

1. Learn More:

2. VSTS Product Backlog Hierarchy:

3. Out Of The Box VSTS Backlog Hierarchy:

3.1. About VSTS Limitation:

3.2. Microsoft VSTS Docs:

3.3. At A Glance – VSTS Backlog Work Item 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 (WikiPedia).

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 Backlog 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.

Organize your backlog
Shows hierarchy – Organize your backlog > Add child items
Broader discussion of work item hierarchies in the context of process templates: Choose a process in the Agile, CMMI, and Scrum section.

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.

Need an Agile Expert ?

Looking for an expert in Agile Coaching, developing & leading Agile transformations, Agile tools, DevOps strategy and Scrum ?

Send me, Ken Adams, a message on LinkedIn and let’s talk.

VSTS Product Backlog Hierarchy

Learn More:

VSTS Product Backlog Hierarchy:

Out Of The Box VSTS Backlog Hierarchy:

About VSTS Limitation:

Microsoft VSTS Docs:

At A Glance – VSTS Backlog Work Item Hierarchy:

Like this:

Related

Need an Agile Expert ?

Subscribe

VSTS Product Backlog Hierarchy

Learn More:

VSTS Product Backlog Hierarchy:

Out Of The Box VSTS Backlog Hierarchy:

About VSTS Limitation:

Microsoft VSTS Docs:

At A Glance – VSTS Backlog Work Item Hierarchy:

Share this:

Like this:

Related

Need an Agile Expert ?

Subscribe

Tags