Effort via Relations

How to set up Effort via Relations Metric

Adding a metric

There is a new Metrics section in the global settings, which lists all active metrics per account. From that screen, you can also create a new metric by clicking the green "Add" button in the header and selecting "Effort via Relations" from the list of possible new metrics.


For now, this Effort via Relations is the single available "custom" metric that affects Effort data. If it’s not turned on, then the effort is calculated with the "default" metric, which is not visible for the users.


After clicking "add", you will be redirected to the metric settings screen (this also happens when you click the existing metric in the list). There you can choose both basic and custom settings for the metric.


Name and description can be anything you’d like, they exist only to make it easier for the users to navigate through the metric list, and to differentiate one metric from another.

In the list of processes, you should select the ones, whose entities will be affected by this metric. In the following section, you should also select types of entities to calculate the metric for. In the screenshot above, the custom relation-based effort will be calculated for UserStories and Features in all processes.

Different metrics may have their specific settings, like a type of relations for Effort via Relations. For now, there is no fancy UI to configure such things, it’s required to manually enter “raw” JSON values in the "Custom Metric Settings" area.

Here’s the shape of JSON for Effort via Relations metric:

    "relationTypes": [
    "entityTypes": [
    "calculateFromMasterRelations": false,
    "normalization": {
        "defaultValue": 1,
        "source": "Team",
        "sourceCustomField": "Velocity"
relationTypesSpecifies the types of relations which should be included in the calculation. For example, specifying "Dependency” makes entities linked with "Dependency” type participate in the effort calculation, but ignores entities linked with other types, like "Relation” or "Blocker".
entityTypesSpecifies which types of related entities should participate in the calculation. In the example above, only linked Bugs, User Stories and Features will influence the efforts of metric targets.
calculateFromMasterRelationsSpecifies whether Master or Slave related entities affect the calculation. It should be "true" if Master (Inbound) entities should be used, and "false" if Slave (Outbound).
normalizationConfigures the effort normalization behavior. Delete this field if you don’t need the normalization for this metric. See Effort Normalization section below to understand what normalization means.
sourceSpecifies the entity which contains the custom field for normalization. For now "Team" and "Project" are supported.
sourceCustomFieldSpecifies the name of the custom field in the "source" entity, which contains the normalization value for the linked entity. Note that the selected field should be of type Number.
defaultValueSpecifies the default fallback value which should be used when a custom field does not exist or when it has an invalid type (string, date, etc.) or when it has invalid value (for example, when it is less than zero).

So for example, if you want to normalize efforts of linked Epics, and you know that the normalization coefficient is stored in custom field name "MyVelocity" of Epic’s Team, set "source" value to "Team", and "sourceCustomField" to "MyVelocity".


Note that the "Team" option doesn’t work well with the multi-team feature at the moment. It always chooses the most recently added Team.

Check that it works

Create several bugs, change their efforts and progress (for example, by moving them to the final state). Attach these bugs to the target entities in the processes with configured metrics. Efforts and progress of those entities should be changed.

Effort normalization

As linked entities can belong to different teams, using different estimations, there is no guarantee that 1 estimation point of Team A will be equivalent to 1 estimation point of team B, they may differ by a great amount.

That’s when the effort normalization may be required. It tries to unify the effort values using the only thing which is the same for both teams - time.

It assumes that teams have some sort of velocity value (the amount of work done in a time interval, for example, 80 points per week). Using that velocity it’s possible to move the actual efforts of teams to the common base.

If team A does 10 points per week, and team B does 20 points per week, then 1 point of team A is roughly equivalent to 2 points of team B, and we can use that information to calculate the aggregated progress for both teams.

Here is an example of how calculation with effort normalization should work. Here we have a user story with two linked bugs.

EffortCompletedEffortToDoNormalization coefficientNormalized velocity
Bug 1991100010
Bug 240501001

MinVelocity = Min(1000, 100) = 100
Bug1.NormalizedVelocity = Bug1.Velocity / MinVelocity = 1000 / 100 = 10
Bug2.NormalizedVelocity = Bug2.Velocity / MinVelocity = 100 / 100 = 1

= (Bug1.EffortCompleted / Bug1.NormalizedVelocity) + (Bug2.EffortCompleted / Bug2.NormalizedVelocity)
= 99 / 10 + 40 / 1 = 49.9

= (Bug1.EffortToDo / Bug1.NormalizedVelocity) + (Bug2.EffortToDo / Bug2.NormalizedVelocity)
= 1 / 10 + 50 / 1 = 50.1

Effort = EffortCompleted + EffortToDo = 49.9 + 50.1 = 100

Progress = EffortCompleted / Effort = 49.9%