Understanding Echoes data
This document explains how Echoes collect and interprets the data it collects from your integrations.
Echoes manages multiple families of labels, which it keeps it sync across all of the integrations where it is enabled. For the purpose of this documentation we use the format of labels as they appear in GitHub, but they may appear differently depending on the particular integration.
- Intent labels, prefixed by echoes/intent Intent labels correspond to your set of configured outcomes (one label per configured outcome). They express why we are doing a change in the first place. This is the primary set of labels Echoes uses to report on the allocation of efforts.
- Initiative labels, prefixed by echoes/initiative Initiative labels correspond to your set of configured initiatives (one label per configured initiative). An initiative is a weighted set of outcomes, and applying the label for an initiative is equivalent to applying the label for all outcomes that belong to that initiative according to their respective weight.
- , prefixed by echoes/impediments (Optional) Impediments labels can optionally be used to surface challenges encountered while implementing a given change, such as a high level of technical debt, or unclear requirements. This bubbles up into the reports for management to bring the appropriate level of support.
- , prefixed by echoes/effort(Optional) Effort labels are created by default for all repositories. They can optionally be used to influence the weight of a given pull or merge request. All changes are considered to be equally weighted by default, which may not always be true. For example, a change may have taken just 1 hour of effort, while another was the focus of an entire week. This is where effort labels come in handy: they allow you to simply express the effort that went into a change with basic t-shirt sizing.
It is possible for a single pull request to hold multiple intent or initiatives labels expressing that the change contributes to multiple outcomes. When multiple intent labels are present, the effort of that change will be ventilated on the different intents in equal proportion. An initiative can be used when a finer control of the relative weight of the different intents is desired.
It is not possible for a single pull request to hold multiple effort labels as it wouldn't make sense for a change to be both high and low effort. Echoes will ignore multiple labels in this case and fallback on the default value (M).
All accounts have two teams created by default and which cannot be deleted.
- 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 engineer joins the organization and contributes a first pull request. The efforts of that new engineer will be attributed to the undispatched team until she or is is dispatched to one of the other teams. This also makes it possible for Echoes to be adopted progressively over a large organization.
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 definitions 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 must be 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 both multi and mono repositories, as well as with inner source environments.
Effort in Echoes is computed per-team and can be displayed either as a percentage of capacity or as a number of full-time employees (FTE). In percentage, Echoes looks at the distribution of merged contributions on the period and computes the allocation of efforts across intended outcomes and initiatives accordingly. In full-time employees (FTE), Echoes multiplies the result by the number of contributing team members on the period. The FTE display is therefore an approximation which doesn't account for holidays, sick days, or part-time work.
Contributions can be labeled at any time, including after a change has been merged. Keep however in mind that they won't show in the dashboards unless merged.
No, Echoes is designed to be process-agnostic. The insights are examined at the team level, and the differences in number and size of pull requests across different teams does not influence results.
Within a given team, different pull requests may have required different level of efforts, and you can use the echoes labels to capture this.