Data Model and Hierarchy

At a high level, the data model connects three major areas: Work, People and Plans.

The native data elements are connected to each other as it's shown on the diagram below.

You may find it split by steps here.

Space

All the data in your Targetprocess account is saved within common work space. Most items in a workspace are grouped by Projects.

Projects usually represent global work spaces, products, services or systems delivered to your customers, whether internal or external. They are long time live objects and you deactivate them only when a product or service stopped being produced.

Projects can be organized into Programs, which visualize groups of projects with something in common. It could be a family of products, a type of services, a group of systems, or any other of your choice. A project can only belong to one program at a time.

Work

Work in Targetprocess is represented by the following items: Portfolio Epics, Epics, Features, User Stories, Bugs, Requests and Impediments.

Portfolio Epics represent high-level large initiatives, or projects in traditional work management approach, which are used to manage portfolio activities in a company. It’s an optional work level. Quite often Portfolio Epics go across many products and services.

Epics represent high-level product capabilities, service initiatives or large features. They are big enough to span several product releases. One of many groups of teams may work on it.

Features are program-level work items, which represent new product features or smaller activities of implementing new product capabilities. Normally it’s something too large to be implemented during a single iteration, but small enough to fit inside a release.

User Stories represent a distinct piece of customer visible functionality. They usually fit a single team iteration. User Story is the lowest independent entity in Targetprocess, so a project with user stories inside is the simplest data structure you can start with if you don’t need more levels in the work hierarchy.

If needed, user stories can be further broken down into Tasks, smallest work items. They represent personal assignments to be done.

Bugs represent defects, failures or issues found during testing or coming from production and can exist independently, be linked to a User Story or a Feature.

There are also Requests which represent incoming requirements, questions or ideas from external users, and may be used for ideation management or project intake. Requests allow communicating with individuals who don’t have access to Targetprocess and manage related work items once a request is processed.

Impediments represent anything that keeps teams from getting work done. It may also represent potential risks that may affect delivery.

Custom relations can be created between work items, representing dependencies, blockers, duplicates and other relations between items.

Work entities organized into a hierarchy gives you the ability to track the progress of higher level entities (such as portfolio epics) based on the progress of lower level entities (such as features and user stories).

You can customize what different entities are called by changing your Process's terms, and it's possible to set up custom workflows to map your own unique process.

People

People are represented by Users in Targetprocess and can be organized into Teams.

Teams can be cross-functional or can be organized around some specific area or component. A person can belong to several teams.

Users can be assigned to work on multiple projects. Assignment to a project gives a person access to data in it.

People or Teams can be assigned to work items, such as user stories, features and others. The assignment of people to work items means that people are going to do some work on it. A team has to be assigned to a project in order to assign work from this project to this team. Read more about Teams and Projects relations.

Plans

Planning items in Targetprocess are represented by Releases, Team Iterations, Builds and Milestones.

Releases represent a timebox during which a group of teams deliver incremental value in the form of working, tested software or systems. It has a predetermined start and end dates, during which progress is monitored and compared with planned velocity.

Team Iterations are shorter fixed-length timeboxes, used by Agile Teams to plan work and track progress.

Builds represent a version of the software, delivered (or not delivered in case of bugs) to production. It includes all the released work items, such as Features, User Stories, Bugs for example.

Milestones are used to represent important company events such as upcoming trade-shows, a new regulation or a meeting with a strategic committee.

Planning entities represent a period of time or a date during which a certain amount of work should be completed.

Planning entities represent a set period of time during which a defined scope of work should be completed. The diagram above describes what planning entities are available in Targetprocess.

Testing Module

There is an additional structure of items that belongs to the test management area in Targetprocess.

For every work and planning entity, you can create a related test plan which contains a set of lower-level Test Plans and individual Test Cases. This way you can create a set of test cases to a user story, feature or any other work item. A Test Plan can be executed multiple times. Every time you’d like to run it you need to create a related Test Plan Run which will have a set of Test Case Runs and Test Plan Runs accordingly. Bugs can be linked to a Test Case Run, to an appropriate Test Plan Run and then to a related entity if it exists. Please notice the test plans can also exist with no relation to a work or plan item.

Read more about the Test Area in Targetprocess.

Extended Data Model / Scaled Agile Framework® Support

Recently we announced support for additional entities specific to Scaled Agile Framework® and new solutions in Targetprocess. They are Agile Release Trains (ARTs), Solution Trains, Objectives and Key Results, PI Objectives and Iteration Goals, Risks, Retrospectives, Action Items and Feedbacks, Dependencies. Being able to rename Epics into Capabilities and Releases into Program Increments (PIs), while work items are expected to be released within Builds and Packages, we support SAFe Data Structure. Find the updated data model grouped into solutions below:

Overview video

• Data Model Video