Setting up Your Item Type Hierarchy
To create a Portfolio workstream map that can track all your work, we are going to define a few things about the items that will eventually be managed inside the map.
To do this effectively, we need to define your hierarchy of item types.
In DevStride, a unit of work or effort is called an item. An item defines something you want to go do.
An item type hierarchy employs a taxonomy as a way to manage the kind of work (items) that is being done. It is often referred to as an agile hierarchy.
It's a very useful way to identify what you want to call your larger groups of work, and what you wish to name the smaller, and smaller units of work underneath them.
In a very small organization, tasks might be managed just as a fairly flat list.
As organizations get bigger, they might have bigger initiatives that break into smaller projects and tasks. That's where the idea of item types comes in.
Item types allow organizations to create a hierarchy so that big ideas and projects can be broken down into smaller and smaller units of work so that they work has context (an item type - is it a big item like a module, or a small unit of work in your hierarchy, like a task) and a home (in the workstream map).
Example: At DevStride, we use the following item type hierarchy for tracking Product Development work:
Module → Capability → Epic → Story and Defect
You can create as many item hierarchies as you would like.
Touring an Example:
To see how this works we will look at an example. This functionality is under, Settings > Item Types (1). The Manage Item Types displays an organization's item types.
The image below is an example of DevStride's item type hierarchy (2). You can name your own.
Note that in our organization, we have a few different item type hierarchies that we can track (2 - 4).
DevStride allows you to create and name your item types, decide how many you need, and how deep they go.
How to Do it
Step 2: Create Your Item Type Hierarchy
To create a new item type or a new hierarchy of items, navigate to Item types under Settings and click on New Item Type (5).
You can name your item types anything you want. For some organizations, an item type hierarchy might be as simple as:
Objective → Task
How to Do it - Item Type Hierarchy Click on Settings then Item Types (1). Then click on the green New Item Type button on the top right corner (2).
Name the highest level of your item hierarchy in the pop-up box under Label (3). In our example, we are using Module as our top-level item category. We do not need to select a parent at this point (4), because Module is at the top. We can then choose its display color. (5)
We want the Modules that we will be working on to break down into smaller ideas or objectives and smaller pieces of work.
For our example, we will name this smaller type of work—and the next level down in our hierarchy—"Capability." (1) Then we can assign it as a child level of Module (2) and choose its display color (3).
If you forget to add the item to its parent, you can edit it as long as there is no work assigned to it.
And because there is no work of this item type in the system, we can still edit its place in the hierarchy by clicking on the edit pencil. Then, simply choose its parent from the dropdown (1).
Note: Time is tracked on the lowest child level(s) as indicated here (1), so that all time can be rolled up to each parent above it.
Be thoughtful about designing your hierarchy. You can change your hierarchy and its labels until you have content assigned with these item types.
Changing the hierarchy after content is added would fundamentally change your data model and all the reporting associated with it, etc.
If you need to change your hierarchy after you have started managing content in DevStride, please reach out to DevStride Support.
Once you start creating content in DevStride there are a few basic rules concerning your item type hierarchy:
You can delete things assigned as the top level of your hierarchy (in our example above, Modules). In this case, the system would simply archive that top level and anything associated with it.
You can delete the bottom level of your hierarchy (in our example above, Story or Defects) because there are no children.
You cannot delete items that are in the middle of a hierarchy. That is because they have inherent dependencies and data associated with them—as designed. The system would not know how to resolve the data tree (in other words, the dependent data) later.
Also note that you cannot inject levels into the middle after content is added. It's best to put a placeholder in now, rather than reordering things in the middle later. So, if you think you might use an item level at some point, add it now.
If you need to make changes to the middle of your hierarchy after getting started, please contact DevStride Support - we'll help you resolve the issue.
Different types of work? No problem!
A marketing team's work, for example, won't look like a product's team work. Instead, a marketing team might have a hierarchy that looks like this:
Client (or Initiative if internal) → Campaign → Objectives →Tasks
Some teams might use multiple types of item hierarchies. There is no limit.
Here's an example of multiple hierarchies - in this case, one for marketing, one for organization initiatives, and one for product engineering:
Next up: Populating and Managing Workstreams