Inquiry Question 1: How are large-scale software solutions developed and managed?
Use project management tools to plan, track and communicate work across a software team, including issue trackers, Kanban boards and Gantt charts
A focused answer to the HSC Software Engineering Module 4 dot point on project management tools. Issue trackers (GitHub Issues, Jira), Kanban boards, Gantt charts, the worked example, and the traps markers look for.
Reviewed by: AI editorial process; not yet individually human-reviewed
Have a quick question? Jump to the Q&A page
What this dot point is asking
NESA wants you to identify the standard project management tools used in software teams and describe what each is for. You should know issue trackers, Kanban boards and Gantt charts at minimum.
The answer
Issue trackers
The central list of work. Each issue captures one task, bug, or piece of work. Common fields:
- Title: a short summary.
- Description: details, acceptance criteria, links to specifications.
- Assignee: who is doing it.
- Labels or tags: categorisation (bug, feature, security, documentation).
- Priority: how urgent.
- Milestone or release: when it ships.
- Discussion thread: comments from team members.
- Status: open, in progress, in review, closed.
Examples: GitHub Issues, GitLab Issues, Jira, Linear, Asana.
Issues form the source of truth for "what needs doing". They link to commits, pull requests, design documents and customer reports.
Kanban boards
A visual board with columns (typically: Backlog, To do, In progress, In review, Done). Each card on the board is an issue. The board shows the workflow at a glance:
Backlog (12) | To do (3) | In progress (2) | In review (1) | Done (8)
--------------|---------------|-----------------|---------------|---------
login form | search bar | password reset | dashboard | signup form
forgot-pass | dark mode | profile page | | nav menu
delete-account| | | | logout
| | | | ...
Benefits:
- Everyone sees what is happening.
- Bottlenecks (a pile-up in "In review") are visible.
- Work-in-progress (WIP) limits prevent overload (no more than 3 items in "In progress" per person).
Most issue trackers (GitHub Projects, Jira, Trello) include a Kanban view.
Gantt charts
A chart with tasks as rows, time on the horizontal axis, bars showing duration. Dependencies between tasks are drawn as arrows.
Task | Week 1 | Week 2 | Week 3 | Week 4
Requirements ####
Design ####
Build ##########
Test ####
Deploy ##
Useful for:
- Time-based planning (when does each task happen).
- Dependency tracking (Task B cannot start until Task A finishes).
- Communicating schedules to non-technical stakeholders.
- Identifying the critical path - the longest chain of dependent tasks that determines the earliest possible end date.
Tools: Microsoft Project, GanttPRO, ProjectLibre, even spreadsheets.
The diagram below shows a five-task Gantt chart with its critical path highlighted: the chain of tasks with zero slack, where any delay pushes back the whole project.
When to use each
| Question | Tool |
|---|---|
| What is left to do? | Issue tracker |
| What is happening right now? | Kanban board |
| When will the project finish? | Gantt chart |
| Who is working on what? | Issue tracker (assignee) |
| Where is the bottleneck? | Kanban board |
| What is the critical path? | Gantt chart |
Combining the tools
A typical small team setup:
- GitHub Issues as the issue tracker. Every bug, feature and task is an issue.
- GitHub Projects as the Kanban board. Issues are automatically added as cards and move through columns as PRs open and close.
- A Gantt chart in spreadsheet form, updated weekly, for the project plan reported to the teacher or stakeholder.
A larger team setup:
- Jira for issues with custom workflows.
- Confluence for documentation linked from Jira tickets.
- Slack or Microsoft Teams for real-time communication.
- Microsoft Project for the high-level Gantt chart.
Other tools
- Wiki / documentation: Confluence, Notion, GitHub wiki. The team's institutional memory.
- Communication: Slack, Teams, Discord. Synchronous chat.
- Roadmap: a higher-level plan than a sprint backlog, typically quarterly.
- Burn-down chart: progress through a sprint, showing remaining work over time.
- Velocity chart: how much work the team completes per sprint, used for forecasting.
Worked: a four-person team
A four-person Software Engineering Project group:
- GitHub Issues: every task captured. Issues labelled by module (backend, frontend, database, ML).
- GitHub Projects board: To do, In progress, In review, Done columns. Each member moves their own cards.
- A Gantt chart in Google Sheets, owned by the project leader, updated weekly. Shows the seven major milestones (planning, design, build, test, deploy, demo, write-up) and inter-task dependencies.
- Daily 10-minute stand-up to talk through any blockers visible on the board.
- A shared Google Doc for design notes, decisions and meeting minutes.
The teacher reviews the Gantt chart in fortnightly check-ins. The team uses the board day to day.
Exam-style practice questions
Practice questions written in the style of NESA exam questions on this dot point, with worked answer explainers. The year tag is the paper they imitate, not the source.
2025 HSC4 marksDescribe the role of an issue tracker, a Kanban board and a Gantt chart in managing a software project. Identify which tool you would use to communicate progress to a non-technical stakeholder.Show worked answer →
An issue tracker (GitHub Issues, Jira, Linear) is the central list of all work items. Each issue captures one task or bug, with a title, description, assignee, labels, priority, and discussion thread. It is the canonical source of "what needs doing".
A Kanban board is a visual representation of the issues moving through states (To do, In progress, In review, Done). It shows the team's workflow at a glance, exposes bottlenecks, and enforces work-in-progress limits. Built into GitHub Projects, Jira and Trello.
A Gantt chart plots tasks against time, showing start dates, end dates, durations and dependencies. Best for projects with fixed deadlines and inter-task dependencies. Used in waterfall and hybrid projects to visualise the schedule.
For a non-technical stakeholder (a school principal, a client, a parent), the Gantt chart is usually the right tool. It answers their questions: when does the project finish? what is happening this month? what is at risk? The issue tracker is too detailed; the Kanban board lacks the time dimension.
Markers reward correct definitions of all three tools, the role each plays, and a defensible recommendation with reasoning (Gantt for time-based stakeholder reporting is the standard answer).
Practice questions
Original practice questions graded from foundation to exam level, each with a full worked solution. Try them before revealing the solution.
foundation3 marksDefine an issue tracker, a Kanban board and a Gantt chart in one sentence each.Show worked solution →
Issue tracker: the central, canonical list of all work items (tasks, bugs, features), each captured as a single issue with a description, assignee and status.
Kanban board: a visual board showing issues as cards moving through workflow columns (such as To do, In progress, Done), giving an at-a-glance view of current state.
Gantt chart: a chart plotting tasks against time, showing start dates, durations and dependencies, used to plan schedules and find the critical path.
Marking criteria: 1 mark per correct, distinct definition (a definition that just repeats the tool's name without describing its function does not earn the mark).
foundation3 marksState which project management tool you would use to answer each question: (a) Who is working on the login feature right now? (b) When will the whole project be finished? (c) What tasks remain in the backlog?Show worked solution →
(a) Kanban board (or the issue tracker's assignee field) - it shows who is actively working on which card right now.
(b) Gantt chart - only it plots tasks against time and shows the dependency chain to a finish date.
(c) Issue tracker - the backlog is the full list of not-yet-started issues, which lives in the tracker rather than the board or chart.
Marking criteria: 1 mark per correct tool matched to its question; award (a) also if "issue tracker (assignee)" is stated with justification.
core5 marksSTIMULUS. A team's Kanban board snapshot shows: Backlog (14), To do (2), In progress (5), In review (9), Done (6), for a team of 5 people with an agreed WIP limit of 2 items in progress per person. (a) Identify the problem visible in this snapshot. (b) Recommend a specific action to fix it.Show worked solution →
(a) The problem. "In review" holds 9 cards, more than any other active column and close to double "In progress" (5) and "To do" (2) combined. This is a classic bottleneck: work is being started and even completed faster than it can be reviewed, so finished work is piling up waiting rather than reaching Done. The In progress count of 5 across 5 people (1 each) is within the WIP limit of 2 per person, so the bottleneck is specifically at the review stage, not at starting new work.
(b) Recommended action. Temporarily stop pulling new cards into "In progress" (or even move a person off new feature work) and have team members pair on clearing the review backlog until "In review" falls back near a sustainable size (for example, below 3). This directly targets the bottleneck rather than adding more unfinished work upstream, which would only make the pile-up worse.
Marking criteria: 1 mark for correctly identifying "In review" as the bottleneck (not just "too much work"), 1 mark for reasoning using the WIP limit correctly (In progress is within limit), 1 mark for a specific corrective action (stop starting new work / redirect people to review), 1 mark for explaining why the action targets the actual constraint, 1 mark for referencing the board's role in making the bottleneck visible at a glance.
core4 marksA project's Gantt chart shows: Requirements (Week 1), Design (Week 2, depends on Requirements), Build (Weeks 3-4, depends on Design), Test (Week 5, depends on Build). Explain what happens to the project's finish date if Design overruns by one week, and name the concept that explains why.Show worked solution →
Because Build cannot start until Design finishes, and Test cannot start until Build finishes, every task in this chain is directly dependent on the one before it with no parallel path and therefore no slack. If Design overruns by one week, Build's start (and therefore Test's start, and therefore the project finish date) is pushed back by one week as well, an exact one-for-one delay.
The concept is the critical path: the longest chain of dependent tasks, which has zero slack, so any delay to a task ON the critical path delays the whole project by the same amount. (If a task is NOT on the critical path, it can slip somewhat without affecting the finish date, because other, longer chains still bound the schedule.)
Marking criteria: 1 mark for correctly tracing the one-week delay through each dependent task, 1 mark for stating the finish date moves by exactly one week, 1 mark for naming the critical path, 1 mark for explaining why critical-path tasks have zero slack (as opposed to off-path tasks).
core5 marksExplain why a two-person Major Project team introducing Jira, Confluence, Notion and a dedicated Gantt chart tool simultaneously is likely to hurt rather than help their productivity, and recommend a more appropriate toolset.Show worked solution →
Each of these tools solves a coordination problem that scales with team size and communication overhead: Jira's custom workflows, Confluence's cross-linked documentation spaces and a dedicated Gantt tool exist to manage coordination among many people working on many interdependent streams. A two-person team has almost no coordination overhead to manage (there are only two people to keep in sync, most days spent talking to each other directly), so the time spent configuring, learning and maintaining four separate tools is pure overhead with no matching benefit, and likely exceeds the time saved.
A more appropriate toolset for two people: a single GitHub Issues + GitHub Projects board (issue tracker and Kanban view in one place, already tied to their code) and one shared document (a Google Doc or a markdown file in the repo) for design notes, decisions and a lightweight weekly plan. This gives them a record of tasks, a visual sense of progress, and a decision log, without maintenance overhead disproportionate to the team's size.
Marking criteria: 1 mark for identifying that these tools solve coordination problems that scale with team size, 1 mark for explaining that a two-person team has minimal coordination overhead, 1 mark for concluding the setup cost exceeds the benefit ("over-tooling"), 1 mark for a concrete, appropriately minimal recommended toolset, 1 mark for justifying why the recommended toolset still covers the essential functions (tracking, visualising, recording decisions).
exam6 marksJustify, with reference to a specific project scenario, why a team should use BOTH a Kanban board AND a Gantt chart rather than relying on just one of the two.Show worked solution →
This is a 6-mark JUSTIFY: markers reward a reasoned argument grounded in a concrete scenario, contrasting what each tool alone would miss.
- Scenario
- A five-person Software Engineering Project team is building a web application with a fixed six-week deadline (the assessment submission date) and a demo day in week 5 that other tasks depend on.
- What a Kanban board alone would miss
- A Kanban board shows only the CURRENT state of work (what is in progress, what is stuck in review) with no time dimension. It cannot answer "will we make the week 5 demo?" because it has no concept of dates, durations or dependencies; a healthy-looking board (few cards stuck) says nothing about whether the remaining backlog can physically fit before the fixed deadline.
- What a Gantt chart alone would miss
- A Gantt chart shows the planned schedule and critical path but is normally updated only periodically (weekly), so it does not show minute-to-minute reality: which specific task is blocked right now, or that reviews have piled up today. Relying on it alone means the team could be silently stuck for days without the schedule visibly reflecting it until the next update.
- Why both, together
- The Gantt chart answers the strategic question (are we still on track for the fixed week 5 demo and week 6 submission, and what is the critical path we must protect), while the Kanban board answers the tactical, daily question (what is blocking us right now, where is today's bottleneck). A team that only tracked the Gantt chart could miss a review bottleneck for a week; a team that only watched the board could discover in week 5, too late, that the critical path had slipped.
Marking criteria: 1 mark for a scenario with a genuine fixed deadline and dependency, 2 marks for correctly explaining what the Kanban board alone would miss (no time dimension / cannot assess deadline risk), 2 marks for correctly explaining what the Gantt chart alone would miss (no daily/tactical visibility), 1 mark for an explicit synthesis of why using both together closes both gaps.
exam6 marksA four-person team is six weeks from their Major Project deadline and has fallen roughly two weeks behind their original Gantt chart schedule. Using the three tools (issue tracker, Kanban board, Gantt chart), propose and justify a recovery plan.Show worked solution →
A strong answer uses each tool for a distinct part of the recovery, not just "work harder."
- Issue tracker: re-scope
- Re-prioritise the backlog against the marking criteria; move genuinely optional ("nice to have") features into a clearly labelled "cut" or "next release" list so effort concentrates only on what is actually assessed. This directly recovers time without needing to work faster.
- Gantt chart: protect the critical path
- Re-identify the critical path under the new, later start point. Any task NOT on the critical path is a candidate to cut, shorten, or run in parallel with critical-path work by reassigning a team member; time saved off-path does not help, so effort should go specifically onto the tasks that are on the critical chain to the deadline.
- Kanban board: enforce flow
- Tighten the WIP limit (for example, one item in progress per person) so effort is not spread across many half-finished tasks, and watch for a review bottleneck (a pile-up in "In review"): if found, pair on reviews immediately rather than letting finished work sit idle.
Why this combination works, and a straight "everyone try harder" would not: re-scoping (issue tracker) reduces total remaining work, protecting the critical path (Gantt) ensures the reduced work still meets the fixed deadline rather than just doing less of everything evenly, and enforcing flow (Kanban) prevents the classic failure mode under time pressure of starting many tasks at once and finishing none. Each tool targets a different cause of schedule slippage (too much scope, wrong tasks prioritised, and inefficient flow respectively), so using only one would leave the other causes unaddressed.
Marking criteria: 1 mark for a re-scoping action using the issue tracker, 1 mark for a critical-path-protecting action using the Gantt chart, 1 mark for a flow-enforcing action using the Kanban board, 1 mark each for correctly justifying why that specific tool is the right lever for that specific cause of slippage (3 marks), with the final mark reserved for an explicit synthesis of why all three together outperform a single generic response.