Task configuration

On this page you will find a list of all task properties to schedule projects.

Account

The account property declares the name of the Account where bookings, like chargeonstart or chargeonend will be made on.

Example

tasks:
  - task: Test
    account: billing

Active

Type: Boolean

With the active flag, you can completely disable a task. Keep in mind that this might influence scheduling of resources in the past, if you use this flag in a task configuration.

It is strongly recommended to only use this flag as part of a task update.

Example

tasks:
  - task: Test
    active: false

Assign

Type: String, list of resource names

With assign you tell TaskFalcon which resources are available for completing a task. You also need to provide the efforts this task will require.

You can provide a comma separated list of resources:

tasks:
  - task: T1
    efforts: 5d
    assign: dev1, dev2

In this example, TaskFalcon will try to assign dev1 to the task, if available. If dev1 is not free at the time the task starts, it will move on to dev2.

You can also tell TaskFalcon that a task requires multiple resources to be available at the same time, for example when a task requires the cooperation of multiple people for completing a task or if besides a human resource, the task also requires a room or special tools to be available. This can be configured with a “+”.

tasks:
  - task: T1
    efforts: 5d
    assign: dev1 + room1, dev2 + room1

In this example TaskFalcon may choose between the combination of dev1 and room1 or the combination of dev2 and room1. As you can see, no matter who will work on this - room1 always has to be free at that time.

Resource assignments can also be combined with filters for limiting the working time of a resource and with roles for accounting. See Filters and Roles for more details.

Buffer

Type: Duration

A buffer adds additional efforts to a task. The purpose is to separate the realistic estimation of efforts from a security buffer to mitigate the risk to slip deadlines.

The difference between adding a buffer and increasing efforts by the same amount is, that the buffer only applies to the projection phase of the project (i.e. the time starting from today until the end of the project). Tasks in the execution phase (the time between the beginning of the project until today) will just ignore the buffer.

Example

Let’s say you’re planning two completely unrelated tasks with 4 days worth of efforts each and you have added a buffer of 2 days to one of the tasks. Let’s assume you have a milestone depending on each task and you communicated the date of this milestone with a customer.

In the beginning of this project task A looks like it takes 6 days to complete while task B takes 4 days. As soon as you come to end of day 4, both tasks will be completed, since now the actual efforts have been completed and the task is done. The previously added buffer does not matter anymore.

In the following animation we see the behaviour described above, but now we have three depending tasks in a row. In both examples the first and the third task both finish as scheduled but the second tasks takes 2 days longer than expected. All tasks in Project B have two days of buffer each.

In the beginning the scheduler assumes that Project A will need 3 x 4 = 12 days to complete and the Milestone A will reflect this. Project B will need 3 x 6 = 18 working days to complete, since each task consists of 4 days of work and 2 days buffer. Halfway through the second task both projects now realise that the current task takes 2 days longer than expected. And while this breaks the milestone for Project A, thanks to the buffers, Project B is still on track.

Buffer

Chargeonstart/Chargeonend

When using the accounting capabilities of TaskFalcon, you can use the properties chargeonstart and chargeonend to charge a fee when the current task has started and/or finished.

Example

  - task: Project Development
    efforts: 100d
    account: Development
    chargeonstart: 2000.00   # e.g. initial cost for hardware
    chargeonend: 8000.00     # e.g. final cost for hardware

Depends

Type: String, list of relative IDs

This adds a dependency to a task or milestone. The task will begin as soon as the dependencies are met (i.e. the depending tasks have been completed). If combined with start, the task will start when start date has been reached and the dependencies are met.

Dependencies are configured as a comma separated list of relative task IDs. To navigate up in the hierarchy a task ID has to be prefixed with ~. See examples.

Example

tasks:
  - group: G1
    tasks:
    - task: T1
        length: 10d
    - task: T2
        length: 10d
        depends: T1         # Depends on the task T1 of group G1
  - group: G2
    tasks:
    - task: T1
        length: 10d
        depends: ~G1.T1     # Depends on task T1 of parent group G1
    - task: T2
        length: 10d
        depends: T1         # Depends on the task T1 of group G2
  - milestone: M1
    depends: G1.T1, G2.T1   # Depends on both T1 tasks of both groups G1 and G2

Description

Type: String

The description just contains a more detailed explanation of the task. It has no meaning to the scheduler. Keep in mind that you can write multi-line texts in yaml, using the block style indicator > or |, where > will conserve new lines, while | will remove additional new lines.

Example

tasks:
  - task: T1
    name: Task 1
    description: >
      This is the first task for this project.
      It needs to be completed first, since it contains
      the required preparation for the real work.      
    length: 10d
  - task: T2
    name: Task 2
    depends: T1
    description: Here we do the real work
    length: 10d

Efforts

Type: Duration

Efforts describes how much work needs to be done to complete this task. It contains a duration (see duration). Efforts always require resources to be assigned to the task, otherwise it won’t get done.

Efforts can only be configured for tasks but not for milestones or groups.

Example

resources:
  - resource: r1
  - resource: r2

tasks:
  - task: T1
    name: Task 1
    efforts: 10d
    assign: r1
  - task: T2
    name: Task 2
    efforts: 20d
    assign: r1+r2

End

Type: Date

By using this property, you can tell TaskFalcon when a task is supposed to be completed.

Example

tasks:
  - task: T1
    start: 2020-06-01
    end: 2020-06-10

Task/Milestone/Group

Type: String

Each task/milestone/group starts with the keyword task, milestone or group and an ID.

The ID is the main identifier of a task, milestone or group. In a hierarchical task configuration, the fully qualified identifier is a string composed of all the parent group identifiers, separated with a “.”.

This might explain why it is not recommended to use a “.” as part of the ID in the task definition, since this will interfere with the task hierarchy. It is recommended to keep the task ID as simple as possible, to make the task easier to be referenced in another task’s dependencies. However, for making incremental task updates in an update section, it is reasonable to use “.” in the task ID, when updating a specific task in the task hierarchy.

Example

tasks:
  - task: T1          # This task has a fully qualified ID of "T1"
    length: 5d
  - group: Subtasks   # This group creates a new scope for subsequent tasks, prefixing their IDs with "Subtasks."
    tasks:
      - task: T2      # The fully qualified ID for this task is "Subtasks.T2"
        length: 5d
      - milestone: M1 # The fully qualified ID for this milestone is "Subtasks.M1"
        depends: T2

Length

Type: Duration

The length setting defines the time this task will need to be completed. Opposed to efforts, the length does not require resources to be assigned.

Efforts can only be configured for tasks but not for milestones or groups.

Example

tasks:
  - task: T1
    length: 5d
  - task: T2
    length: 1w 2d

Link

Type: String

In this field you can track external links (e.g. Jira or any external tools). This has no effect on the scheduler, but the link will also be included in text based output formats (JSON/CSV/XLS).

Example

tasks:
  - task: T1
    name: Task 1
    link: https://my.jira.com/issues/PROJECT-23
    length: 10d

Locked

Type: Boolean

With the locked setting, a task can be excluded from rescheduling during an update.

When processing updates, the update will reschedule all tasks, that start or end after the update timestamp. For certain tasks, this might not be desirable (e.g. you’ve communicated a milestone with a customer and don’t want TaskFalcon to change this due to indirectly related changes in the config).

Unlike tasks, milestones are always locked by default. This is to ensure you don’t accidentally miss a deadline without noticing when one of the direct or indirect milestone dependencies change.

If you want a milestone to automatically move based on the latest update of its dependencies, you would need to unlock it. If you only want to keep the milestone locked, but you need to reschedule it explicitly due to a change of plans, you might want to have a look at the reschedule option.

Example

In this example T1 will finish on 2020-06-03 without considering the update. This sets the reference date for M1, which is now locked.

The update will trigger a rescheduling of T1. Since M2 has been unlocked, it will automatically be rescheduled to the new end date. However, M1 will now be shown with a broken dependency, since it is still locked to the previous date.

# File: locked.yaml
project: 
  name: Locked
  start: 2020-06-01

tasks:
  - task: T1
    start: 2020-06-01
    length: 3d

  - milestone: M1
    depends: T1
    locked: true # this line is actually not required, since
                 # milestones are locked by default
  - milestone: M2
    depends: T1
    locked: false

updates:
  - update: 2020-06-02
    tasks:
      - task: T1
        length: 5d

Result:

Locked

Name

Type: String

The name of a task is an optional property to make the task easier to read in the generated documents.

Example

tasks:
  - task: T1
    name: Installation and setup of working environment
    length: 5d

Priority

Type: Number

Intuitively you might think, that priority will influence the order in which tasks are scheduled. While there is some truth to it, it is important to understand, that priority does not influence the start or completion of tasks directly. Instead, priority determines the order in which tasks will be assigned resources in case of a resource conflict.

The default priority of a task is 100. A higher value makes the task more likely to get the assigned resources.

The keyword priority has no effect on a task without efforts or assigned resources.

Example 1

tasks:
  - task: T1
    assign: dev1
    length: 5d
    priority: 200
  - task: T2
    assign: dev1
    length: 5d
    priority: 100

In this example, T1 will be completed before T2. Both tasks start at the same time, but require the same resource dev1. Since T1 has a higher priority, it will be given dev1 first, so it will be completed before T2.

Example 2

tasks:
  - task: T1
    assign: dev1
    length: 5d
    priority: 200
  - task: T2
    assign: dev2
    length: 5d
    priority: 100
  - task: T3
    assign: dev1
    length: 5d
    priority: 150

In this example, T1 will be completed before T3, since both tasks require the same resource dev1. This time, T2 is using a different resource and will be completed before T3, despite T3 having a higher priority than T2.

Role

When booking resources for tracking the project’s finances, you need to declare how to charge a resource that is working on a task. One way of doing this is by declaring a role on a task.

This is covered with examples on the Accounting page.

Start

Type: Date

By using this property, you can tell TaskFalcon when a task is supposed to be started.

Example

tasks:
  - task: T1
    start: 2020-06-01
    end: 2020-06-10

Tasks

Type: List of tasks

This property is only allowed in groups. In a group this will define a list of sub-tasks for this group.

Example

tasks:                              # This is the top level "tasks" section of your project
  - group: G1                      
    name: A simple group of tasks
    tasks:                          # This "tasks" section adds more tasks to this group
      - task: T1                    
        name: The first task of G1
      - task: T2                    
        name: The second task of G1

Task Type

Type: Special

Each element underneath tasks: must be one of three different types:

A group of tasks
A group is allowed to contain more tasks in its own tasks section. It may not list efforts or resources itself
A milestone
A milestone is just a point in time, which consists of a start date or dependencies, but does not contain resources or efforts.
A task
A task is the most important element of a plan, since this is where the actual work gets done.

The type is given by how the element starts:

tasks:
  - group: G1                       # Determines that the type of G1 is a group
    name: A simple group of tasks
    tasks:
      - task: T1                    # Determines that the type of T1 is a task
        name: The first task
      - milestone: M1               # Determines that the type of M1 is a milestone
        name: This milestone is completed after the first task
        depends: T1

Tracking

Type: String

The value for tracking determines the tracking policy of TaskFalcon. It decides whether TaskFalcon assumes that resources work on tasks according to plan or via explicit bookings. It can assume two different values: auto (default) and explicit:

Automatic tracking with keyword `auto`

Automatic tracking is the default behaviour of TaskFalcon. TaskFalcon automatically schedules tasks in the future and assumes that all work in the past has been done according to plan.

A project manager tracking a project with this policy needs to make sure that the assumption of the scheduler since the last project review holds true or he needs to change the plan accordingly.

Explicit tracking with keyword `explicit`

Explicit tracking also schedules tasks in the future automatically, but only considers work in the past that has been booked explicitly via a booking entry.

A project manager tracking a project with this policy needs explicitly needs to tell the scheduler which resource was working for how many hours on each task since the last review. Generally, this is the safer option but it also requires more manual editing.

The parameter tracking only influences how the scheduler handles work in the past. Future work will be scheduled equally no matter the selected tracking policy.

You can also set tracking: explicit on a group or project level to block tasks from starting automatically. You then have the option to do explicit bookings on tasks or just use another update to set tracking: auto on a task level. This can sometimes give you a better control about when tasks are supposed to start. It also can help handling task priorities, since when all other tasks are blocked due to tracking: explicit than the only task that isn’t blocked will be given the resources no matter if there are tasks with a higher priority.

Example

Let’s assume you’ve created a project plan for a project that will start today and will take one employee one week to complete.

Since the default behaviour is tracking: auto, if you schedule the same project again in a week without making changes it will be done.

If you set tracking: explicit, then after one week the scheduler will tell you that you still have one week of work left to do, since you didn’t tell TaskFalcon that work has been done on the project.

To make some progress, you need to add some booking entries.

# File: tracking.yaml
project:
  name: Tracking
  start: 2020-06-01

resources:
  - resource: w1
    name: Worker 1

  - resource: w2
    name: Worker 2

tasks:
   # T1 starts on 2020-06-01. 
   # The tracking policy here is "auto", which means that TaskFalcon assumes
   # that everything works out as scheduled. 
   # Hence the task will be completed after 5 working days.
    - task: T1
      start: 2020-06-01
      efforts: 5d
      assign: w1
   # T2 also starts on 2020-06-01. It uses explicit tracking, but no
   # bookings have been made. 
   # After one week it still hasn't started making any progress
    - task: T2
      start: 2020-06-01
      efforts: 5d
      assign: w2
      tracking: explicit
    # T3 starts 2 weeks after project start. While it also uses explicit tracking, 
    # the task is in the future, so it will be scheduled the same way
    # a task with automatic tracking would
    - task: T3
      start: 2020-06-15
      efforts: 5d
      assign: w1
      tracking: explicit

    # The following milestones are just for a better visualisation
    # in the example animation
    - milestone: Update 1
      start: 2020-06-08
    - milestone: Update 2
      start: 2020-06-17
    - milestone: End of project
      start: 2020-06-20

updates:
  # In the first update, we let TaskFalcon know, that Worker 2 now has 
  # started working on task T2.
  # Worker 3 also has started working on T3, despite the fact that T3
  # was supposed to start on 2020-06-15
  - update: 2020-06-08
    tasks:
      - task: T2
        bookings:
          w2: 5d
      - task: T3
        bookings:
          w1: 3d # w1 only works for 3 days on T3, so the task will not be completed
  # In the second update we finish the remaining work of T3
  - update: 2020-06-17
    tasks:
      - task: T3
        bookings:
          w1: 3d # w1 works again 3 days on T3, despite the fact that it was supposed
                 # to have only 2 days worth of efforts left

In the following animation, the above example is scheduled day by day. You can see that tasks with tracking: explicit will schedule everything as usual in the future, but only consider explicit booking records for the past (left side of today). We only have two updates with resource bookings, so some of the work will get pushed further away until a resource gets assigned explicitly in one of those updates.

Tracking

See bookings for more details.

Work Limits: DailyMax, WeeklyMax, MonthlyMax

Type: Duration

With the properties dailymax, weeklymax and monthlymax you can limit the amount of time resources can spend on a task per day/week/month. This can be used to model ongoing support tasks with a limited amount of efforts per time.

You can use those properties individually or in any combination you like.

Example

project:
  name: Daily/Weekly/Monthly Max
  start: 2020-06-01

resources:
  - resource: r1
    name: Somebody

tasks:
  - task: T1
    name: DailyMax 2h
    dailymax: 2h
    efforts: 1d
    assign: r1

  - task: T2
    name: WeeklyMax 2h
    weeklymax: 2h
    efforts: 1d
    assign: r1

  - task: T3
    name: DailyMax 2h + WeeklyMax 6h
    dailymax: 2h
    weeklymax: 6h
    efforts: 3d
    assign: r1

  - task: T4
    name: MonthlyMax 2h
    monthlymax: 2h
    efforts: 4h
    assign: r1

Task configuration

Table of contents

Account

Example

Active

Example

Assign

Buffer

Example

Chargeonstart/Chargeonend

Example

Depends

Example

Description

Example

Efforts

Example

End

Example

Task/Milestone/Group

Example

Length

Example

Link

Example

Locked

Example

Name

Example

Priority

Example 1

Example 2

Role

Start

Example

Tasks

Example

Tags

Task Type

Tracking

Automatic tracking with keyword auto

Explicit tracking with keyword explicit

Example

Work Limits: DailyMax, WeeklyMax, MonthlyMax

Example

Automatic tracking with keyword `auto`

Explicit tracking with keyword `explicit`