Gantt charts for YouTrack. Web app that builds a Gantt chart from the issues in a YouTrack saved search. Includes both the past (reconstructed from activity log) and the future (computed from issue metadata).
- Web app that builds a project plan and visualizes it as Gantt chart using (only) data that already exists in the issue tracker.
- Since the Gantt chart is computed using available issue metadata, it is always always up to date. No editing required.
- See below for a detailed description.
- Runs entirely in the browser. No installation required by users. (As a one-time setup, the YouTrack administrator needs to add the URI of the web app to the so-called “Resource Sharing” settings in YouTrack. For convenience, it is also a good idea – though not necessary – if the administrator installs the YouTrack workflow fschopp/remaining-effort-youtrack-workflow.)
- No separate login required for this web app (assuming the user is already logged into YouTrack).
- Available for immediate use at: https://fschopp.github.io/gantt-for-you-track/
- This web app never comes in touch with user passwords (thanks to OAuth 2.0).
- For maximum peace of mind, it is always possible to fork this repository and/or host this web app yourself.
- Based on:
- fschopp/project-planning-ui-for-you-track for the user-interface framework and for configuring the connection to YouTrack.
- fschopp/project-planning-for-you-track for the communication with YouTrack.
- fschopp/project-planning-js for the list-scheduling algorithm used for scheduling unresolved issues.
- adamhaile/S.js and adamhaile/Surplus for reactive programming of the user interface.
- dhtmlxGantt for the Gantt widget.
- Written in TypeScript.
- Partial source code documentation available. Generated by TypeDoc.
- Test coverage is currently incomplete. However, the underlying algorithm packages fschopp/project-planning-js and fschopp/project-planning-for-you-track have complete test coverage.
GNU General Public License, version 2 (same as dhtmlxGantt)
- See the corresponding section in project fschopp/project-planning-ui-for-you-track. The description there applies for this project as well.
Gantt charts are bar charts that visualize project schedules. Their main appeal over other schedule representations (purely textual, precedence diagrams, etc.) is simplicity and intuitive interpretation. They have arguably become the de-facto standard for presenting project schedules, and there is relatively little variance with respect to visualization. However, different tools are quite different in how they support the creation of a project schedule. Not mutually exclusive categories are:
- Manual scheduling. The tool allows the planner to freely sort issues and change their start and end times. The freedom may even include the ability to create non-sensical schedules.
- Convenient editing. The tool assists the planner with manual schedling. For instance, when extending the duration of an issue by x days, it automatically shifts all dependents by x days, too.
- Declarative scheduling. The tool computes a schedule from the given constraints (dependencies, earliest possible start time, available contributors, each assignee’s weekly availability, etc.).
- Reconstructing schedule from activity log. The tool creates the actual (historic) schedule from the activity log (say, start date = time when state in issue tracker was changed to “in progress,” end date = time when issue was resolved, etc.).
There are also various alternatives for storing project schedules:
- Store schedule in issue tracker. If an issue tracker keeps a rich enough activity log, this is essentially a given for the past schedule. Otherwise, custom fields in the issue tracker can be used. For the future planned schedule, however, relying only on custom fields makes it difficult to store multiple project schedules (say, a best-case and worst-case schedule).
- Store part or all of the schedule in a separate system. This is possible with various levels of integration with the issue tracker (hooks, periodic synchronization, etc.). A separate system obviously allows for multiple schedules or otherwise extended metadata, but it abandons the principle of treating the issue tracker as “single source of truth,” and it can create synchronization challenges.
- No storage. This is possible if scheduling is declarative.
- Provide scheduling options 3 and 4 (“Declarative scheduling” and “Reconstructing schedule from activity log”) and storage option 3 (“No storage”).
- Be agnostic about issue-tracker configuration. Where certain data is required, at least be agnostic to naming.
- Support heterogeneous teams (different locations, different hours, different fields of work).
This web app distinguishes:
- Elapsed time (aka duration). Cohn (2006, “Agile Estimating and Planning”) defines this as “the amount of time that passes on a clock (or perhaps a calendar).”
- Ideal time (aka effort or work). This, in contrast, is the “amount of time that something takes when stripped of all peripheral activities” (ibid.). Ideal time also does not contain time off work (such as nights or weekend).
Issues in the issue tracker are expected to have a field containing the remaining effort, measured in ideal time. The time axis in a Gantt chart instead shows the calendar time. Therefore, the length of a bar in the Gantt chart represents elapsed time.
Generally speaking, project scheduling needs to take into consideration that contributors (in fact, all resources) are available on different timelines. For example, people may work in different time zones, they take vacations, or they have different weekly availabilities.
Currently, this tool only allows to specify contributors’ weekly availabilities, but not time zones or planned time off. Work by different contributors is converted to calendar time by simple interpolation. That is, a contributor available x min/w is assumed to be constantly working at a rate of (x min/w) / (7d/w · 24h/d · 60min/h). In other words, this is the contributor-specific burndown of ideal time per elapsed time. While interpolation is arguably less realistic than using contributors’ individual work schedules (say, Monday through Friday, between 9am and 5pm GMT), it has the benefit of simplicity, and is usually sufficient for estimation purposes.
Using project fschopp/project-planning-js, the problem of scheduling issues is transformed (“reduced”) to a machine-scheduling problem, which is then solved using the list-scheduling algorithm from project fschopp/project-planning-js.
For scheduling purposes, all issues are assumed to be interruptable (also called preemptable), as long as each resulting issue activity has an ideal effort of at least 4 hours. Optionally, certain issue types can be defined as “splittable.” This allows issues to be split among more than one contributor, as long as each resulting activity has again an ideal effort of at least the previous preemption threshold. Splitting among multiple contributors can be useful if the project contains large issues (often called epics) that are not yet broken down into smaller tasks.
Since the list-scheduling algorithm is used, the order of the issues has crucial influence on the resulting project schedule. This tool processes issues in the same order as they appear in the YouTrack saved search. Sometimes it may be necessary to override this order. While YouTrack allows to manually reorder the issues in a saved search, this feature may become cumbersome with many issues. This web app therefore allows to configure an “overlay” saved search in order to reorder only a subset of the issues. As an example, suppose the issues in the main saved search are A, B, C, D (in that order), and the issues in the overlay saved search are F, D, E, B. In this case, issues E and F are ignored (because they are not contained in the main saved search). The remaining issues B and D must appear in the overlay order, but any issue not in the overlay must be left in place. Consequently, the final order for the algorithm is A, D, C, B.
Issues are scheduled in input order as described above, subject to issue dependencies. If an issue A depends on another issue B, then both A and its sub-issues are assumed to (transitively) depend on both B and all of B’s sub-issues. Beyond that, parent-child relationships do not influence the scheduling order. That is, if both an issue and a sub-issue have non-zero remaining effort, then both issues’ own (excluding sub-issues) processing will occur in input order.
Ideally, any issue tracker providing sufficient metadata would be supported, but for now this web app only supports JetBrains YouTrack.
The overall design goals of the YouTrack built-in Gantt report appear similar to our goals above. The report provides scheduling option 3 (“Declarative scheduling”) and storage option 3 (“No storage”). Note, however, that it does not provide scheduling option 4 (“Reconstructing schedule from activity log”). Additionally, there are other important differences. Unlike the YouTrack report, this web app:
- Supports contributors with different weekly availabilities (see also YouTrack issues JT-44405, JT-50080).
- Treats Gantt charts as merely representation of the underlying project schedule, so Gantt visualization options do not affect the schedule (see JT-52034).
- Supports wait times (such as for approvals, deliveries, etc.), where the assignee is not busy any more but dependent issues cannot be scheduled yet.
- Supports splitting issues among multiple contributors.
- Uses the activity log for reconstructing the past project schedule. In contrast, the YouTrack built-in Gantt report ignores the activity log, and its computed project schedule does not generally match the actual project history (see screenshots in manual).
- Only considers each issue’s remaining effort when computing the future project schedule. In contrast, the YouTrack built-in Gantt report typically computes a project schedule based off the issues’ total estimation or spent time. It schedules issues in full (that is, not just their remaining effort), including those issues that have already been worked on or that even have been resolved (see screenshots in manual).
- Is open-source. You can examine the scheduling algorithm and modify it if needed.
- Cohn (2006): “Agile Estimating and Planning,” Prentice Hall, ISBN 9780131479418.