CS375: Software Engineering - Task Dependencies: Gantt Charts and the Critical Path
Activity Goals
The goals of this activity are:- To explain the critical path in software projects
- To estimate task duration
- To plan a timeline incorporating task time estimates and dependencies using a Gantt chart
- To convert a GitHub Projects kanban board into a Gantt chart timeline using Mermaid
- To assign an owner to every task so that the Gantt chart doubles as a work assignment plan
Supplemental Reading
Feel free to visit these resources for supplemental background reading material.- Online Gantt Chart Creator
- Beta Distributions and Task Scheduling
- GitHub Projects Documentation
- Mermaid Gantt Chart Syntax
The Activity
Directions
Consider the activity models and answer the questions provided. First reflect on these questions on your own briefly, before discussing and comparing your thoughts with your group. Appoint one member of your group to discuss your findings with the class, and the rest of the group should help that member prepare their response. Answer each question individually from the activity, and compare with your group to prepare for our whole-class discussion. After class, think about the questions in the reflective prompt and respond to those individually in your notebook. Report out on areas of disagreement or items for which you and your group identified alternative approaches. Write down and report out questions you encountered along the way for group discussion.Model 1: Gantt Charts
| Activity | Predecessor | Time estimates (in days) | Expected time (TE) | ||
|---|---|---|---|---|---|
| Opt. (O) | Normal (M) | Pess. (P) | |||
| a | — | 2 | 4 | 6 | 4.00 |
| b | — | 3 | 5 | 9 | 5.33 |
| c | a | 4 | 5 | 7 | 5.17 |
| d | a | 4 | 6 | 10 | 6.33 |
| e | b, c | 4 | 5 | 7 | 5.17 |
| f | d | 3 | 4 | 8 | 4.50 |
| g | e | 3 | 5 | 8 | 5.17 |
Questions
- In terms of scheduling, what determines if a task is on the critical path?
- The expected time estimate of a task is given by a Beta Distribution over the optimistic time, the most likely time, and the pessimistic time. It is a weighted average of the optimistic time, the pessimistic time, and four times the most likely time. Write this formula and verify the time estimates in the table above.
- Create a table of expected tasks for the semester for your project, and a Gantt chart, which you will include in your requirements report.
- Explore a tool like Asana or Trello for creating Kanban board that you can share with your group. Describe what a Kanban is.
From Kanban Board to Gantt Chart with GitHub Projects
Real software teams rarely draw their Gantt charts by hand. Instead, they track their work as issues on a kanban board (in GitHub Projects, Trello, Asana, or Jira), and generate a timeline view from that board. In this walkthrough, you will practice this the way a real team does it on GitHub: create issues, organize them on a Projects kanban board, and then render the same plan as a Gantt chart using Mermaid, a text-based diagramming language that GitHub renders automatically inside any Markdown file, issue, or README.
Step 1: Capture Your Tasks as GitHub Issues
Every row of your Gantt chart should begin its life as a GitHub issue. For each task on your project plan:
- In your project repository, click Issues, then New issue.
- Give the issue a short, action-oriented title (for example, “Implement login endpoint”).
- In the description, note the estimated duration (using your optimistic/normal/pessimistic estimates from the model above) and any issues it depends on (for example, “Blocked by #3”).
- Assign an owner: in the right sidebar, use the Assignees field to name exactly one teammate responsible for the task. Tasks without an owner tend not to get done; tasks with two owners tend to get done twice (differently!).
Step 2: Organize the Issues on a Kanban Board
From your repository or organization, click Projects, then New project, and choose the Board template. You will see the classic kanban columns: Todo, In Progress, and Done. Add each of your issues to the board. GitHub Projects also provides built-in Roadmap view: if you add custom Start date and Target date fields to your project items, the Roadmap view will draw a timeline for you automatically – this is a kanban-to-Gantt conversion built right into GitHub, and you are welcome to use it for your project.
Step 3: Render the Plan as a Mermaid Gantt Chart
To publish the timeline in your requirements report and README, convert the board into a Mermaid gantt diagram. Each issue becomes one task line with an ID, a start date (or a dependency), and a duration. Here is a fully worked two-sprint example for a small team building a course-scheduling web app. Suppose the board contains these issues:
| Issue | Title | Assignee | Estimate | Depends On |
|---|---|---|---|---|
| #1 | Design database schema | Alice | 4 days | – |
| #2 | Implement login endpoint | Bob | 5 days | #1 |
| #3 | Build course listing page | Carol | 5 days | #1 |
| #4 | Sprint 1 demo and retrospective | All | 1 day | #2, #3 |
| #5 | Implement enrollment endpoint | Bob | 5 days | #2 |
| #6 | Build enrollment page | Carol | 4 days | #3, #5 |
| #7 | Write user acceptance test scripts | Alice | 3 days | #4 |
| #8 | Sprint 2 demo and retrospective | All | 1 day | #6, #7 |
Pasting the following code block into any Markdown file on GitHub (such as your project README) renders it as a graphical Gantt chart – try it!
```mermaid
gantt
title Course Scheduler: Sprints 1 and 2
dateFormat YYYY-MM-DD
excludes weekends
section Alice
Design database schema (#1) :done, t1, 2025-02-03, 4d
Write acceptance test scripts (#7):t7, after t4, 3d
section Bob
Implement login endpoint (#2) :active, t2, after t1, 5d
Implement enrollment endpoint (#5):t5, after t2, 5d
section Carol
Build course listing page (#3) :active, t3, after t1, 5d
Build enrollment page (#6) :t6, after t3 t5, 4d
section Whole Team
Sprint 1 demo (#4) :milestone, t4, after t2 t3, 1d
Sprint 2 demo (#8) :milestone, t8, after t6 t7, 1d
```
Notice several things about this chart:
- Each
sectionis a person. Grouping tasks by assignee makes the chart double as a work assignment plan: you can see at a glance who owns each task, and whether anyone is overloaded (two of Carol’s tasks overlapping, for example, would be a red flag). - Dependencies use
after. The taskt6beginsafter t3 t5, exactly mirroring the “Depends On” column of the issue table. This is how the critical path becomes visible: follow the longest chain ofafterlinks. - Issue numbers appear in the task names (
#1,#2, …), cross-referencing each Gantt row back to the GitHub issue (and kanban card) that tracks it. - Status keywords like
done,active, andmilestonevisually distinguish completed work, current work, and sprint boundaries.
Step 4: Keep Them in Sync
Your kanban board is the living view of the plan (cards move daily), while the Gantt chart is the scheduled view (dates and dependencies). At each sprint boundary, update the Mermaid chart to mark completed tasks done and to reschedule anything that slipped. Note whether the slip affects the critical path, and discuss schedule adjustments at your standup meeting.
Your Turn
- Create a GitHub Project kanban board for your course project, populate it with issues for your first two sprints, and assign exactly one owner to every issue.
- Convert the board into a Mermaid Gantt chart in your project README, with one section per team member, an issue number on every task, and
afterdependencies matching your issue dependencies. - Identify the critical path in your chart. Which person owns the most critical-path tasks? Would re-assigning any task shorten your schedule?
For your requirements report: your Gantt chart must include an owner (assignee) for every task – either by using one Mermaid section per person as shown above, or by including an assignee column in an accompanying task table. Unowned tasks will be treated as unplanned work.