Understanding the skill, resource and team model

Applies to

Definition

LYNX separates resources (who can do work) from skills (what work they can do), and connects the two with a many-to-many relationship: one resource can hold several skills, and one skill can be implemented by several resources. Properties add competencies on top of a skill (such as seniority, location or language), and teams group resources for team-based assignment.

Purpose

Separating resource from skill is what lets a plan be built before anyone commits to who, specifically, will do the work: a task can require "Software Engineer" without naming a person, and LYNX can reason about how much of that skill exists across the whole space. Properties exist for the cases where the skill alone is not specific enough: when a task genuinely needs someone with, for example, both the right skill and the right seniority or location.

Key concepts

Example

A task needs more than "someone with the System Tester skill". It needs a tester who works on a particular product group. A property expresses that requirement.

A property is defined as a property class: a name, plus the unit of measure that supplies its possible values. Where that unit of measure is a picklist, the picklist's values become the values the property can take. Properties are therefore not free text. They are built on the space's units of measure, which is what keeps them consistent wherever they are used.

A resource is not always a person

A space's resource list can hold equipment alongside people. This one contains Crane - Large and Crane - Small next to named individuals. Anything with finite capacity that work can be planned against is a resource, and the same skill and property machinery applies to it.

Related articles

• Configuring skills and resources
• Choosing how to assign work: skill, property, virtual skill or resource
• LYNX Resource Management Cycle (not yet written; see backlog.yml)

Revision history