Planning

Background

There are two different time planning levels within ictime:

1. Work estimates on task/sub-task level (this functionality is provided by JIRA and ictime uses the data).
2. Planning/estimates on component and project level.

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 for project and maybe component,
• 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.

Time Planning Method

We distinguish a top-down time budget and a bottom-up time budget.

This means that we have three levels where we can manage and view plan values and can compare them with time already spent:

1. Project.
2. Component.
3. Task.

According to the planning approach explained above, we use a specific logic

When calculating viewing the project time planning sheet, we proceed according to the following logic:

As long as there is plan value set for a component and/or for the complete project, we always show this plan value.

If there is no plan value set on component or project level, we show the value resulting

and in addition we show the values for the component and project that are resulting from plan values on the n

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.