How are release/iteration effort fields calculated? (Plan, Task, Actual, Remaining, Projected, Available)

Friday, February 6, 2015 3:57:33 PM

release iteration effort plan task actual remaining projected available

Would you please confirm or correct the following table about how the release/iteration effort fields are calculated?

Please note that there are three Enhancement Requests included below and the report of one possible defect.

I have not been able to find definitive definitions though I reviewed the online help and also questions in this forum. There are effort/hour columns on a lot of SpiraTeam entities (e.g. release/iteration, incident, task, requirement) and it's very difficult to understand the relationship between them all.

Enhancement request: Please include these kind of calculated field definitions in the actual user interface itself. For example, put a question mark icon next to the label for each and every calculated field (not just these six) and when a user hovers his mouse cursor over the icon then the definition should appear.

RELEASE/ITERATION COLUMN	DEFINITION. HOW IS IT CALCULATED?	ARE THE VALUES ROLLED UP FROM CHILD RELEASES/ITERATIONS TO THEIR PARENTS?
Plan Effort	= ((The "# Resources" times the number of working days, inclusively, between the "Start Date" and "End Date") times the "Work Hours Per Day") minus (the "# Non Work Days" times the "Work Hours Per Day"). Roughly synonymous with a top-down estimate. Whether a particular date is a working day depends on the Admin > Planning Option "Work Days Per Week". If the option is 5, then the working days are M, T, W, R, F. If it is 6, then Saturday is a working day. The "Work Hours Per Day" is set on the Admin > Planning Option page. "Plan Effort" is not affected by any child data. It is not affected by child Iterations. It is not affected by child Requirements, child Tasks, child Incidents, etc.	No.
Task Effort	= All child Task "Est. Effort" plus child Incident "Est. Effort". Roughly synonymous with a bottom-up, task-driven estimate. Only the direct children's values are included. The values for Tasks or Incidents that are merely related through an association tab are not included. The Requirement "Est. Effort" value is not included. (Incidentally, a Requirement "Est. Effort" is based on the Requirement "Estimate" field. Enhancement Request: Please rename this Release/Iteration column from "Task Effort" to "Est. Effort". That will help users better understand where its source values comes from.	Yes.
Actual Effort	= All child Task "Actual Effort" plus child Incident "Actual Effort". The Requirement column "Actual Effort" is not an editable column and it is not included in the sum. (It is itself a calculated column that sums the Tasks that are children of the Requirement.)	Yes.
Remaining Effort	= All child Task "Remaining Effort" plus child Incident "Remaining Effort". Synonymous with an Estimate To Completion (ETC). Only the direct children's values are included. The values for Tasks or Incidents that are merely related through an association tab are not included. The Requirement column "Remaining Effort" is not an editable column and it is not included in the sum. (It is itself a calculated column that sums the Tasks that are children of the Requirement.)	Yes.
Projected Effort	= All child Task "Projected Effort" plus child Incident "Projected Effort". Synonymous with an Estimate At Completion (EAC). This column is a sum of values that are themselves calculated values. On any one Task, Incident, or Requirement row, the "Projected Effort" column equals that row's "Actual Effort" plus that row's "Remaining Effort". As a result, a row's "Projected Effort" can be more or less than the row's original estimated "Task Effort", and it can be used to evaluate the accuracy of that "Task Effort". Only the direct children's values are included. The values for Tasks or Incidents that are merely related through an association tab are not included. The Requirement column "Projected Effort" is not an editable column and it is not included in the sum. (It is itself a calculated column that sums the Tasks that are children of the Requirement.)	Yes.
Available Effort	= The Release/Iteration row's "Plan Effort" minus the row's "Projected Effort". Roughly synonymous with the Available Resource Capacity at the level of the Release/Iteration row. A parent Release will appear to have more "Available Effort" than its children Iterations if it has more resources than the sum of its children and has the same dates, or if it has the same number of resources as that sum but its duration is greater. Or some combination thereof. A parent Release will appear to have less "Available Effort" than its children Iterations if it has less resources than the sum of its children and has the same dates, or if it has the same number of resources as that sum but its duration is less. Or some combination thereof. These discrepancies occur because Plan Effort is not rolled up. It is calculated separately for each Release/Iteration row based on that row's own resources and dates. Also, SpiraTeam does not require an Iteration's dates to be the same as or inside its parent Release dates. Enhancement request: Don't allow an Iteration's dates to be outside of its parent Release's dates. Defect(?) Report: It doesn't seem to make sense that this column and its source columns (Plan Effort and # Resources) do not roll up. It feels like each row should have a "# Resources" and a "Sum Resources" column, and then each row's Plan Effort should be based on the "Sum Resources". This will preclude the defective-looking Available Effort values that currently exist when there is a mismatch between the number of resources and dates on a parent release versus its child iterations.	No.

1 Replies

Friday, February 6, 2015 5:19:58 PM

jfreed

re: jfreed on Friday, February 6, 2015 3:57:33 PM

CORRECTION:

This can be a bit confusing, but here goes:

A Release/Iteration's "Task Effort" and "Projected Effort" also include in their sums the "Est. Effort" of every child Requirement when:

the child requirement does not itself have child Tasks, and
when the child requirement does have child Tasks, but those Tasks' hours have not been updated since the Task was made a child of the requirement.

Defect(?) Report: Item #2, above. To expand upon that, It does not seem right that a Release/Iteration includes a child Requirement's hours when the Requirement has a Task until that Task's hours are updated. Instead, it seems that as soon as a Requirement has a child Task, that child Task's hours should be used for the parent Release/Iteration. (It seems that there is a trigger that is executed to update the Release/Iteration when a Task hours are updated and that that trigger should also be executed when a Task is made a child of a Requirement.)

QUESTION: How do child row statuses affect the calculations if at all? E.g. Requirement statuses, Task statuses, Incident statuses.

Statistics

Started: Friday, February 6, 2015 3:57:33 PM
Last Reply: Friday, February 6, 2015 5:19:58 PM
Replies: 1
Views: 2342

How are release/iteration effort fields calculated? (Plan, Task, Actual, Remaining, Projected, Available)

Edit Thread

Edit Message

Search Results