How Chalmers Students Used Kanban for a Capstone Project

The case study of how Chalmers students used Kanban to manage a capstone project offers a practical view of visual planning in a demanding academic setting. A small group in Gothenburg had to turn a broad assignment into a sequence of testable outputs while coordinating supervisors, technical specialists and industry contacts. The team made work visible on a Kanban board, gave each item an owner and controlled how many items moved at once. This created a dependable rhythm without forcing every status meeting to reconstruct the project from scratch.

Within Celean, the Chalmers Electronic Lean Research Team, the case connects classroom practice to research into lean processes, enterprise systems, digital visual management and prototype software tools. Kanban was useful because it exposed uncertainty: which item was genuinely ready, where work had stalled and whose decision was needed next. For Australian teams, the method transfers readily into engineering, software and consulting projects, provided the board reflects real commitments and flow remains a shared responsibility rather than a reporting exercise for one project manager.

Why the capstone needed visible work

A capstone group begins with several possible paths rather than an ordered task list. Early research, prototype development, documentation, testing and demonstration all matter, yet each depends on decisions made by someone else. When those dependencies live only in notebooks and chat messages, students can appear busy while the integrated deliverable quietly slips. Chalmers students treated the board as a map of the real workflow, including work still under discussion and work waiting for review. A task completed in one student’s personal list could therefore still be blocking progress elsewhere.

The board used familiar stages such as Backlog, Ready, In progress, Review and Done. Cards represented outcomes or small, verifiable steps, with an owner, expected completion point and visible blocker. Swimlanes separated streams where useful, such as research and development. Most importantly, work in progress, or WIP, had a limit. A pull system let students choose the next ready card only when capacity existed, so finishing became more important than opening fresh work.

The board also established a short communication cadence. A team check-in focused on cards that had moved, cards that had aged and cards awaiting a decision. The team used retrospectives to adjust the rules, changing a troublesome lane, clarifying acceptance criteria or moving a card back when it was not actually ready. This made Kanban more than a visual to-do list: it was a feedback mechanism connecting planning, execution and review. The board became a shared operating agreement that anyone joining the project could read and question.

Board rules that kept work visible

The team introduced the board with deliberate restraint. Cards did not carry long narratives, and the workflow did not duplicate every function of an enterprise system. Each card held enough information for another student to understand the intended output, current state and next action. The following operating rules kept attention on flow:

• Every card named one owner and one verifiable output.
• Ready work had agreed acceptance criteria before it entered the active lane.
• WIP limits stopped one student from absorbing the whole team’s capacity.
• Blocked cards showed the reason and the person able to unblock them.
• The board was updated before the team check-in, so the board, not a slide deck, held the status.
• Ageing and blocked work was discussed before new tasks were pulled.
• Decisions were recorded beside the card they affected.
• Each weekly cycle ended with a retrospective and a forecast for the next cycle.

A written update made the board easier to use beyond the room. A simple weekly blog gave supervisors and partners a readable account of progress, and weekly blog guidance helped the students keep each entry short. The posts recorded completed outcomes, open risks and the next intended result rather than narrating every meeting. This was useful for people joining at different times, but it complemented the board; it never became another place where cards had to be maintained twice.

How the board changed team decisions

When the board became the status meeting, reporting changed. Instead of asking each student for a verbal update, the group walked through exceptions: a card with no clear owner, a review waiting too long or a dependency that needed escalation. Completed cards provided a shared history, so a new supervisor could understand the project without receiving a separate briefing. The visual record also made invisible coordination work, such as preparing a test environment or clarifying a requirement, easier to discuss.

Limiting WIP changed the quality of attention. Rather than opening five half-finished activities, students closed one item, checked it and exposed the next constraint. Pair review became more reliable because reviewers could see when work was ready for them, and integration stopped being a Friday surprise. Flow was not measured by card count; a board full of “In progress” cards exposed a problem, while an empty active lane could be healthy if the team had genuinely reached a boundary.

The case also shows why a board needs an owner and a renewal rhythm. Project Visit’s account of Celean tool adoption describes how research prototypes become useful in operating practice when teams receive training, adapt tools to actual work and keep feedback between developers and users. The same principle applies in a capstone: a tool should reduce searching and uncertainty, while the team retains responsibility for priorities, quality and the consequences of its decisions. A visually attractive board cannot compensate for unclear authority or neglected maintenance.

Reading the case from an Australian perspective

Australian readers will recognise the basic setting. Engineering, design and business students in Melbourne, Sydney and Brisbane often complete capstone projects around a multidisciplinary brief, a prototype and an assessed final presentation. Course teams routinely need evidence for supervisors and industry reviewers, and an audit trail of decisions can be as valuable as the final artefact. Kanban gives that trail a simple shape without replacing formal assessment, academic ethics approval or the documentation required by a client agreement.

Hybrid work makes the visual board particularly relevant. Australian project groups often meet through Microsoft Teams, Slack or a university learning platform, then use a quick stand-up before the workday and written handovers for colleagues in another time zone. A shared screen showing the board prevents the meeting from becoming a round of disconnected status reports. If an Australian team works with an overseas partner or a Perth-based colleague, the same rule applies: publish the card state before the handover and identify the one decision needed from the next person.

The local technology market offers many ways to support this practice. Trello, Jira, Miro and Smartsheet can host simple Kanban flows, while Australian small and medium-sized engineering, construction and consulting firms often favour cloud tools that work across a laptop, tablet and meeting-room display. The board’s value does not depend on a costly enterprise licence. A familiar interface, clear ownership and disciplined updates matter more, especially for a small consultancy that cannot dedicate a full operations team to tool administration.

Visual task control also has legal and safety boundaries in Australia. State and territory work health and safety laws based on the Safe Work Australia model require risk management, training and appropriate supervision for fieldwork and construction; a Kanban card cannot replace those controls or a site induction. Where the Privacy Act 1988 and Australian Privacy Principles apply, client or participant information should be minimised, access-controlled and kept only as long as required. Teams should also separate public progress notes from confidential intellectual property and use approved university or company storage.

Carrying the method into industry

The transition from a student board to an organisation is where many methods lose momentum. Project Visit has documented Volvo visual planning trials, showing how new software can be tested against operational needs and how feedback from practitioners changes both the tool and the surrounding process. This is a useful model for the capstone team: the board should help people make and deliver work, not become a demonstration that only the project manager understands.

The case suggests three durable lessons. First, represent outcomes rather than vague activities, because “validated concept” creates different planning decisions from “read papers”. Second, set limits using observed capacity and revise them through retrospectives; arbitrary targets create theatre. Third, retain a visible definition of done so quality belongs to the shared system. These lessons also expose the limits of the method. Kanban cannot resolve unclear authority, incompatible incentives or unrealistic scope by itself.

The concrete next step is a one-week pilot: create cards for the next three deliverables, set a WIP limit for active work, and update the board at the same time each weekday.