Categorizing work

9min
Categorizing work is central to Echoes data collection. There are two aspects to categorizing engineering work:
﻿Tagging efforts﻿. Echoes lets you define your taxonomy of work and provides the tools for frictionless and consistent tagging of engineering efforts at scale.
﻿Attributing efforts to teams﻿. Engineering success in Echoes is measured at the team-level, never for the individual, which makes the attribution of efforts to teams crucial to proper data reporting.
Tagging efforts
Taxonomy
Engineering efforts are tagged using a customizable taxonomy. How engineering efforts are tagged plays a role in all three aspects of success reports:
In measures of alignment﻿ by indicating what the work item is about.
In measures of delivery﻿ in order to compare performance across different areas of work.
In measures of health﻿ when used by engineers to surface challenges faced during implementation.
The taxonomy consists of a combination of categories﻿ and initiatives﻿.
Data consistency
Data consistency for activity reporting is a major pain point, especially at scale. Echoes overcomes this issue by guaranteeing a consistent taxonomy of work across teams and product development tools. Third-party systems are updated live as Echoes configuration evolves. For example, labels and custom fields entries are created as a new dimension node get created; labels and custom field entries disappear as an obsolete initiative gets archived.
Attributing efforts to teams
Default teams
Reports in Echoes are at the team-level, and all registered engineering efforts are attributed to a team. Every organization has two special teams:
Organization root. The root of the organization from which other teams can be created. Like any other team, the root of the organization can have members in it (typically the organization's leadership, or anyone who wants to see the activity of the whole group by default).

Undispatched contributors. The undispatched contributors team is the team where members get created by default, for example when a new joiner contributes their first pull request. The efforts of that new engineer will be attributed to the undispatched team until they are dispatched to one of the other teams. This also makes it possible for Echoes to be adopted progressively over a large organization.
Effort attribution
Contributors in Echoes belong to one and only one team at any point in time, and always contribute on behalf of their team. This make the teams﻿ definition within Echoes particularly important. Every member of the organization has a join date in the team that marks the moment from which this member's contributions are attributed to that team. It is possible to change the join date of a member within a team, and contributions will be reattributed to reflect that change.
Effort attribution is achieved through solely through team membership, and never by looking at the repository where the work was contributed. This makes Echoes compatible with multi and mono repositories setup, as well as with inner source environments.
Frequently asked questions
When should work items be categorized?
Work items can be categorized at any point in time, including after the item is completed. For example, labels can be applied to a GitHub pull request even after it is merged.
Can categorization be automated?
We don't think categorization should be fully automated as it's hard to reliably infer the intent behind a given piece of work. However, some automation is possible using Echoes and third-party platforms features:
Echoes automatically applies to GitHub pull requests and GitLab merge requests the labels it finds on linked issues. For example, a GitHub pull request linked to a JIRA ticket gets its labels automatically applied following the "Echoes - Intent" JIRA custom field. This process also follows parents links, such that a single JIRA EPIC can cascade labels onto dozens of future pull requests.

Echoes initiatives﻿ can be used to eliminate redundant tagging. An initiative can capture in a single location the tags that apply to this entire area of work.

Continuous integration pipelines (e.g., GitHub Actions) can be used to automate the labeling of recurring items. For example, pull requests opened by dependabot can be automatically labeled as "type: maintenance" and "effort: XS".
Can categorization be enforced?
Categorization can be enforced on platforms that support it.
For GitHub, Echoes provides a builtin check﻿ which can be selectively enabled to verify if pull requests have the expected labels.
For GitLab, Echoes provides a reusable job﻿ which can be used to verify if merge requests have the expected labels.
For JIRA, the "Echoes - Intent" custom field can be marked as required﻿ in the field configuration scheme.
Within Echoes, uncategorized efforts are reported as "Untagged" and can be categorized directly from the product.
How are percentages of effort computed?
Echoes looks at the distribution of contributions on the chosen period and computes the allocation of efforts across dimensions and initiatives accordingly. This computation happens at the team-level and doesn't favor teams based on the number of completed items (e.g., merged pull requests or closed tickets). Work items are considered equally weighted by default, but the computation can be influenced using the tags of the special "Effort" dimension.
Can a given work item have multiple tags?
A given work item may have multiple tags.
When the selected tags belong to different dimensions, the work item is categorized across more than a single axis.

When the selected tags belong to the same dimension, the behavior depends on the definition of the dimension:
If the dimension only allows a single value (for example the "Effort" dimension where being both "XS" and "L" doesn't make sense), Echoes ignores the semantically incorrect and uses the default value for the dimension instead.
If the dimension allows multiple values, the weight of the item is distributed equally across the different tags.
﻿
Updated 29 Aug 2024
Did this page help you?
Email report