Categorizing work

categorizing work is central to echoes data collection there are two aspects to categorizing engineering work categorizing work docid\ jwaykgpkxab15b7aeiyli echoes lets you define your taxonomy of work and provides the tools for frictionless and consistent tagging of engineering efforts at scale categorizing work docid\ jwaykgpkxab15b7aeiyli 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 docid\ ao1n6fg6rabn97eofxwhm by indicating what the work item is about in measures of delivery docid\ nxzpm0sifpn2ovbewwiku in order to compare performance across different areas of work in measures of health docid\ icnh6saw92bo4hrmdcoii when used by engineers to surface challenges faced during implementation the taxonomy consists of a combination of categories docid\ v vyntdrcapwmderrjlui and initiatives docid\ auolbydwwbaqfuxrazrpx 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 docid\ jpm4jbk168zwuvnmmwoyy 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 docid\ auolbydwwbaqfuxrazrpx 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 github docid\ sx5k4dytpcgcvkajjzqkj which can be selectively enabled to verify if pull requests have the expected labels for gitlab, echoes provides a gitlab docid\ at0ssiisruecp1zlrtqwd which can be used to verify if merge requests have the expected labels for jira, the "echoes intent" custom field can be jira docid 894ilvdbdj3sdmgz0hm3i 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