Important note Retirement of icTime and Retirement of biz on December 29th, 2023

Planning Concept

ictime provides a central interface to plan time budgets on project, component and issue level.

Please note that planning in ictime is always time-based. Even though you can assign a cost/price to you work for work you log, there is no financial budget planning, but just time-planning. Planning is no resource planning either, it is not about allocating resources to projects, components and issues.


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 at some moment, 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) are derived 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.

When doing the planning and when showing time planning values, we distinguish two kinds of values:

Planning ValuesDescriptionRemarks
genericplan-values entered on this level, you set this valuepossible for components and project; on task level, this is simply the JIRA work estimate
calculatedtime is retrieved from lower levels, you see this value, but can't set itthis 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 for the ictime project time planning sheet:

LevelValueDescription
Sub-Taskgeneric*JIRA work estimate on sub-task level
Issuegeneric*JIRA work estimate on issue level
Componentgenericif 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
 calculatedsum of work estimates of all issues of this component, will be considered to calculate the total for the project if no generic value is set for this component
Projectgenericwill be displayed for information purposes
 calculatedsum of plan values of all components (generic and/or calculated, this is decided on component level)
 * Note ... click here to expand

In fact, JIRA calculates the work estimate for a issues as sum of work estimates of all sub-tasks + the work estimate for the issue 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 issue level. This way, work estimates for sub-tasks are fully considered, but we do not show this as explicit planning level.

Even though it might be difficult to understand in the beginning, it is very simple. It's basically all about the component time planning value. 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 issues/sub-tasks of the component) should be used for calculating the project time budget (bottom-up approach, detailed).

Examples

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, 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.

Now have a look at the same project in a later planning stage:

LevelGenericCalculatedRemarks
Task A1-015h We have made a work estimate of 5h.
Task A1-0210h We have made a work estimate of 10h.
Task A1-0310h We have added this task and have made a work estimate of 10h.
Component A1 = 25hWe 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-0110h  
Task A2-0225h  
Component A2  =35hWe 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 A310h We have planned 10h for component A3. No work estimates for tasks yet, so still no calculated value.
Projekt A = 70hWe 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.

The example above shows a more detailed planning. Except for the component A3, where we do not have tasks with work estimates yet, we have decided to basically rely on the work estimates from task level, and we also have decided that planning is good enough to eliminate the general time budget for the project itself, as the data we get from lower levels is complete enough.

If you don't use components and/or if you have issues without component assignment, such issues will be automatically summed up into a "virtual" component provided by ictime in order not to break the logic that all calculated values always need to come from the next-lower level ("No Component"). You can't set a generic plan value for this "component" of course, but the calculated value will be considered for the project like it were a real component. This way, work estimates on issue level are made available to calculate the planning value for the project without having a real component.