Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

Background

There are two different time planning levels within ictime:

  1. Work estimates on task/sub-task level (this functionality is already provided by JIRA and ictimeuses 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 value on task level.enhances this option by providing a central planning sheet).
  2. Planning/estimates on component and project level. This is extra functionality provided by ictime.
Info

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.

Time Planning Method

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

Time Budget / Planning ValuesDescriptionRemarks
genericplan-values directly entered on this levelpossible for components and project; on the task level, this is simply the JIRA work estimate
calculatedtime is retrieved from lower levelsthis is a value calculated by ictime from available data on the next-lower level; according to the logic explained below

According to the planning approach explained above, we apply a specific logic to calculate and show plan vaues on every level. Have a look at the following example:

LevelGenericCalculatedRemarks
Task A1-015h We have made a work estimate of 5h.
Task A1-0210h We have made a work estimate of 10h.
Component A130h= 15hWe 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 A220h We have planned 30h for component A2. No work estimates for tasks yet, so no calculated value.
Component A310h We have planned 10h for component A3. No work estimates for tasks yet, so no calculated value.
Projekt A100h= 60hWe 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. This way we have decided that we want to use these (rough) values 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.

 

 

If we find a plan value on one level, we use it to calculate the plan value for the next-higher level. If we do not find a plan value on this level, and only in this case, we use the plan values of the next-deeper level.

 

 

 

 

 

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.

 Apart from having two different places to enter time budget planning information, there is also a specific approach for being able to manage rough time budget plans and detailing planning at the same time. This is explained in detail in the following chapters.

Page Tree
root@self

 

...