Background
There are two different time planning levels within ictime:
- 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 uses the value on task level.
- Planning/estimates on component and project level. This is extra functionality provided by ictime.
Please note that planning in ictime is always time-based. Even though you can assign a cost/price to you work for time you log, we do not offer budget planning at this stage, but just time-planning.
Planning Approach
When you plan your project, especially in the beginning, you might only have a very high-level planning (e.g. time budgets on project or component level), and with the time, you can go more into details (tasks, sub-tasks). So you need to start planning with very rough numbers, but of course with the time, you want to benefit from being able to plan more in detail. It also might happen that some people in general prefer to plan top-down and others want to plan bottom-up:
- top-down planning, where planning only takes place on project and maybe component level,
- bottom-up planning, where plan figures for a project or component (only) arise from the plan figures for tasks and sub-tasks.
In fact both approaches have serious disadvantages. The first does not allow for control on lower levels, the second leads to a situation where the planning only gets complete towards the end of the project, because you usually can't pre-define all tasks and sub-tasks in the beginning of a project.
As a conclusion and to cover both needs, you need to set top-down time budgets on a certain level, and at the same time, you want to use bottom-up time budgets that are derived from a more detailed planning on lower levels. How this can be reached is described in the following paragraph.
When doing the planning and when showing plan values, we distinguish two kinds of values:
| Planning Values | Description | Remarks |
|---|---|---|
| generic | plan-values entered on this level, you set this value | possible for components and project; on task level, this is simply the JIRA work estimate |
| calculated | time is retrieved from lower levels, you see this value, but can't set it | this is a value calculated by ictime from available data on the next-lower level according to the logic explained below |
Depending on the level (project, component, task) you are working on, these values have a slightly different idea:
| 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 | |
| calculated | ||
| Project | generic | |
| calculated |
Have a look at the following example:
| 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. | |
| Component A1 | 30h | = 15h | We have planned 30h for component A1, and we have a calculated plan value for this component of 15h from task level. Obviously, the generic value is to high or we are still missing work estoimates for tasks of this component. |
| Component A2 | 20h | We have planned 30h for component A2. No work estimates for tasks yet, so no calculated value. | |
| Component A3 | 10h | We have planned 10h for component A3. No work estimates for tasks yet, so no calculated value. | |
| Projekt A | 100h | = 60h | We have planned 100h on project level. We have a calculated value of 60h from component level. So still some planning to do on lower levels ... |
You remember, we wanted to plan top-down and bottom up at the same time. 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.
Now have a look at the same project in a later planning stage:
| 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.