...
- Work estimates on task/sub-task level (this functionality is provided by JIRA and ictime uses the data). JIRA allows for entering values on the level of sub-task and task, and if both levels have work estimates, they are all added; so ictime usesthe total value on task level (for reasons of simplicity, we are not explicitely showing the sub-task level).
- Planning/estimates on component and project level. This is extra functionality provided by ictime.
...
Depending on the level (project, component, task) you are working on, these values have a slightly different idea for the ictime project time planning sheet:
| Level | Value | Description | |||
|---|---|---|---|---|---|
| Sub-Task | generic* | JIRA work estimate on sub-task level | calculated | n.a.||
| Task | generic* | JIRA work estimate on task level | |||
| calculated | n.a.* | ||||
| Component | generic | if you set this value, it will be considered to calculate the total for the project, if you do not set it, the calculated value for this component will be taken instead | |||
| calculated | sum of work estimates of all tasks of this component, will be considered to calculate the total for the project if no generic value is set for this component | ||||
| Project | generic | will be displayed for information purposes | |||
| calculated | sum of plan values of all components (generic and/or calculated, this is decided on component level) |
| Expand | ||
|---|---|---|
| ||
In fact, JIRA calculates the work estimate for a task as sum of work estimates of all sub-tasks + the work estimate for the task itself; but from ictime planning point of view, this is not a calculated value, as in our project time planning sheet, we do not show the sub-task level, but our starting point is the JIRA work estimate result on task level. |
This way, work estimates for sub-tasks are fully considered, but we do not show this as explicit planning level. |
| Tip |
|---|
Even though it might be difficult to understand in the beginning, it is very simple. By setting a generic plan value on component level, you decide that this value should be used for calculating the results for the project (top-down approach, not very detailed). By not setting it, you decide that the calculated result for the component (= work estimates for all task/sub-tasks of the component) should be used for calculating the project time budget (bottom-up approach, detailed). |
Have a look at the following example:
...
| Tip |
|---|
You remember, we wanted to plan top-down and bottom up at the same time, and the key is how we handle component planning values. The example above shows a planning situation where we are still missing some detailed planning. As we are aware of that, we still have set plan values directly on component level, and we also still maintain a generic value on project level. This way we have decided that we want to use the (rough) component values for calculating the project plan and are not ready yet to replace them by calculated values from task level. All this gets transparent as we can see that generic and calculated values are present and still don't fit very well. |
...
| Level | Generic | Calculated | Remarks |
|---|---|---|---|
| Task A1-01 | 5h | We have made a work estimate of 5h. | |
| Task A1-02 | 10h | We have made a work estimate of 10h. | |
| Task A1-03 | 10h | We have added this task and have made a work estimate of 10h. | |
| Component A1 | = 25h | We have deleted the generic value for component A1, as we have decided that the detailed planning for tasks of this component is ready now. So we only have a calculated plan value for this component of 25h from task level (doing the detailed plan on task level, we also realised that 30h was to much). | |
| Task A2-01 | 10h | ||
| Task A2-02 | 25h | ||
| Component A2 | =35h | We have deleted the generic value for component A2, as we have decided that the detailed planning for tasks of this component is ready now. So we only have a calculated plan value for this component of 25h from task level (doing the detailed plan on task level, we also realised that 20h was not enough). | |
| Component A3 | 10h | We have planned 10h for component A3. No work estimates for tasks yet, so still no calculated value. | |
| Projekt A | = 70h | We have deleted the generic value on project level, as we think that planning for components is now okay and reflects the overall time budget we will need. So we have a calculated value of 70h from component level, and big parts of that planning value is a result of work estimates on task level. |
Even though it might be difficult to understand in the beginning, it is very simple: By setting a generic plan value on component level, you decide that this value should be used for calculating the results for the project (top-down approach, not very detailed). By not setting it, you decide that the calculated result for the component (= work estimates for all task/sub-tasks of the component) should be used for calculating the project time budget (bottom-up approach, detailed).
If you don't use components, XXX
The derived budget is always displayed (and calculated) only between exactly two levels, and it considers derived time budgets as well as generic time budgets. If there is a generic time budget, this is always taken. If not, the derived one is taken.
7.2.3.2 Calculation Rule for Derived Time Budgets
1. Add (sum) all generic time budget entries of one level and always ignore derived time budgets if a position has a generic entry.
2. If a generic time budget entry does not exist, take the derived time budget for this position instead.
3. The result is displayed as derived time budget on the next-higher level.
Rule 1. ensures that we consider the generic entries with preference and do not double entries if there is a generic and a derived one. Rule 2. ensures that we consider the derived values at the moment we do not have a generic one.
This way you proceed - separately! - for every level. It is very important to understand that all derived results displayed are always results from all entries of exactly one level deeper.
7.2.3.3 Examples
The following examples show the way we can enter generic time budgets and the way the derived budgets are calculated on every level:
Level Generic (entered) Derived (calculated)
Project A 100 h = 50 h
Component A1 30 h -
Component A2 20 h = 15 h
Task A21 5 h -
Task A22 10 h = 6 h
Sub-Task A221 3 h -
Sub-Task A221 3 h -
You see that regardless of the existence of derived time budgets, for calculation of the derived time budgets, the higher level always takes the generic budgets from the respective lower level (see calculation rule above).
Project A: 30 h + 20 h = 50 h
Component A2: 5 h + 10 h = 15 h
This is perfectly okay as long as the user thinks that the more detailed planning is not really (almost) completed, so we should still rely on the generic planning numbers from the respective higher levels. This is a decision the user takes, our application does not know anything about it, but just follows the calculation rule.
Let's now assume that our planning for component A2 is complete in detail, so all the tasks and sub-tasks that belong to this component have been created and our user thinks that we have a reliable detailed planning for this component. This means that we now should start to rely on the planning from the lowest level possible. What we do is to delete the generic entry for Component A2 and also the generic entry for Task A22 (remember, our numbers should come from the lowest available level now, as we consider the lowest level the most detailed and reliable). What happens is the following:
Level Generic Derived
Project A 100 h 41 h
Component A1 30 h -
Component A2 11 h
Task A21 5 h -
Task A22 6 h
Sub-Task A221 3 h -
Sub-Task A221 3 h -
You see that now, for calculation of the derived time budgets, the higher level always takes the derived budgets from the respective lower level, if available:
Project A: 30 h + 11 h = 41 h
Component A2: 5 h + 6 h = 11 h
This way, we are completely flexible, and the user decides how he wants to plan. As long as the user considers the detailed planning not ready at all, we rely on planning values from higher levels. At the moment the user considers the detailed planning (for a component or a task) sufficiently valid, the user can decide to delete the generic planning value on the resp. next-higher level and this way the system automatically uses the derived values.
As you can see, for component A1, we go on using the generic values and do not have any detailed planning yet. So at any moment, we can plan in detail or not, and we still could plan only in detail or only on a very high level.If you have tasks without component assignment ... XXX
Setting Plan Values
Target/Actual Comparison