Re-scheduling (effort vs. duration)

Owned by Frank Polscheit
Last updated: May 12, 2016
2 min read

I differenciate between effort and duration of an issue. The effort is reflected by the JIRA field "original effort"  or as aggregation of already logged work and remaining estimated effort. The duration is delimited by planned start and planned end date. For example, if you boss decides to deliver an issue one day earlier to the customer, this has an impact on your planning but not on the estimated effort if the scope is unchanged. Same in case of a change of estimated effort: this may have an impact on the duration but not necessarily.

Within JIRA, you can specify as system administrator the number of working days per week as well as the number of working hours per day as global JIRA parameters. That information is read by my add-on to determine over-allocations. Per user, you can maintain project availabilities (velocity) in %: click on the menu item "Personal Calendar for Gantt-Chart" just below "Profile" on the most top right of your JIRA window. This individual assignee-based information will be used when (re-)scheduling issues. If you have specified e.g. an effort of 3 days of an issue having assigned user A, who is available for that project only by 50%, than the duration from planned start day to planned end day will be 6 working days, taking care that weekends/non-working days are skipped automatically. Currently, there is no configuration per user possible to specify the daily amount of working hours per each day differently.

If you habe less effort, you can keep the original plan end date and regard the difference as buffer to reduce risks or you work on other issues in parallel or ...

If the total amount of effort increases or your reality will not match planning, you have to decide what to do: re-scheduling will NOT be automatically triggered by work logging!

  • you can keep the planned end date and split that task into multiple (sub-)tasks assigned to different team members to match the communicated goal or
  • the assignees have to work longer per day and/or during the weekend or 
  • you re-assign to a more experienced senior team member, who is able to implement the rest of that task faster than the current assignee matching the planned end date or
  • together will all stakeholders you de-scope the content of that task to be ready in time or
  • you deliver later by shifting the planned end date
    BUT: very often, you have restrictions and cannot always move the end date into the future, because contractual penalties or other reasons (delivering Christmas trees in January is not an option!).

In all cases, it is a decision of the project manager or the agile team depending on your local organisation but not an automatic action of a computer program conceptionally. Instead, it is important to assist any decider and focus on such situations (indicated by yellow/red coloring). If you decide to adjust the planned end, then reflect this by explicitely moving the end of the Gantt bar via drag'n drop to the new date. All depending issues as well as subtasks are automatically adjusted accordingly, taken global calender as well as project calender and assignees' calenders into account.