Forums > SpiraTeam Forums > SpiraTeam Issues & Questi... > How are release/iteration...

How are release/iteration effort fields calculated? (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.

Name:
Body:
Tags:

Name:
Body: