Skip to main content
teamspace

Kanban board: make the flow of work visible and steer it.

A kanban board shows work as cards in status columns. A card moves from To do to Done, the state is visible to the whole team, and wherever cards pile up, the bottleneck shows early. In teamspace you run a board for tasks, tickets or a whole project. Part of the teamspace cloud software.

teamspace kanban board with the five statuses To do, In progress, Ready for review, In test and Done. The columns hold task cards with title and assignee; one card moves from In progress to Ready for review and makes the flow of work visible.

Where it fits

Why tasks belong on a board.

Tasks in lists and email

  • The state sits in a column, easy to miss
  • Nobody sees at a glance what is running now
  • Bottlenecks only show when it is too late
  • Everyone keeps asking for the current state

Tasks on the board

  • Every task is a card in its status column
  • The state is visible to the whole team
  • Where cards pile up, the bottleneck shows early
  • The card moves on, the status changes with it

The principle

How the work flows across the board.

Every task is a card and sits in the column of its status. Whoever moved it forward drags it one column to the right, from To do through In progress to Done. So everyone sees where the work stands and where it is stuck.

To do 3

ready to start

In progress 4

someone is on it

API change

5 points · A. Vogt

Ready for review 1

waiting for review

In test 2

being checked

Done 3

finished

A task moves visibly from left to right.

How many cards sit in a column at once, the team sets itself.

Layout

Columns and rows order the flow.

You set up a board to fit how you work, not the other way round. What separates a column and what a row bundles is yours to decide.

  • The columns map status, relevance, owner, element type or group, just as you need.
  • The rows split the board further, for instance per person, per client or per service class.
  • Task cards can be split further and coloured by status, relevance or colour.
  • You drag a status onward with the mouse; the card comes in three sizes, for more or less detail.

So a wall of columns becomes a board that shows your team's reality, not someone else's scheme.

Feature set

What the board can do.

Three board types, one path.

  • Kanban, Scrum and pinboard start with their own statuses
  • Every type can be freely reconfigured
  • Boards flow into one another when needed

Boards fill from the project.

  • Automatically or by hand, from a project, a directory or a person
  • Place tickets, work packages and receipts straight on
  • An element may sit on several boards

The card shows more than a title.

  • Owner, due date and relevance
  • Linked element, comment and icon
  • The footer shows the fields you need

Classic and agile

One work package, two views.

Nobody has to choose between classic and agile. The planned project in the Gantt and the work on the board hang on the same element: the work package.

  • A work package from the project can move onto the board automatically and be worked there in an agile flow.
  • In the structure plan the same package stays classically planned, with progress, budget and owners.
  • The card carries the link to the work package: logged hours land on the package and feed the project's plan vs actual.
  • Completed work is billable that way, without anyone transferring hours into a second tool.

Whoever keeps cards and hours in two worlds knows the collateral damage: cards without an hour link, hours without a card, corrections at month-end. Here it is one item.

Background

When the card is the element.

Behind the scenes teamspace knows two ways to read a card. Which one fits depends on the use case.

Show the list as a board. A set of work packages can be shown as a kanban or scrum board instead of a table, with the columns standing for status. Here the card is the work package itself: drag it into another column and you change the work package's status. It stays the same entity, only shown differently.

The board as its own entity. Alongside that, you can create a board that carries its own cards, where each card points to another element, for example a ticket. Now the card is the thing being moved: it runs its own status, independent of the linked item. On a candidate board, cards are linked to the application tickets. The ticket carries the communication and stands at, say, "answered"; the card carries the selection and stands at "shortlisted" or "schedule interview". The two statuses run separately.

When it is about the status of the work itself, you show the list as a board. When a process of its own should run over the linked items, you create a board with its own cards. teamspace can do both.

“We mostly work with the budget column.”

At the brandwerk consulting group many projects run for years. A board that keeps the state of every task visible replaces the constant asking after where a task currently stands.
brandwerk consulting group

Method

What Kanban actually is.

A kanban board is a method for making work visible and limiting its flow. Cards stand for tasks, columns for the state of work. A card moves from left to right until it is done. The principle began in the 1940s at Toyota, where "kanban" was the signal card for material being pulled in.

Four principles carry the method, whatever the tool:

  • Make work visible: every task shows as a card, and nobody has to check a list for what is running.
  • Limit work in parallel: a WIP limit caps the number of cards per column. It is a team agreement, not an automatism in the software, and keeps multitasking in check.
  • Pull instead of assign: new work is pulled as soon as capacity frees up, rather than dumped on someone.
  • Improve steadily: where cards pile up, the bottleneck shows and the team can talk it through.

In teamspace you map these principles through freely configurable columns and statuses. Running a board online has two hard advantages over a whiteboard: distributed teams work on the same state, and every move stays traceable.

Boards for different teams.

How a board looks depends on the team. Four typical configurations, each with its own columns and rows.

Software development

  • Columns: To do, In development, Review, Test, Done
  • Rows per feature or service
  • Cards from work packages and tickets

Development and maintenance on one board

IT support

  • Columns: New, In progress, Waiting, Closed
  • Rows per priority or client
  • Cards straight from the service-desk tickets

Tickets as cards, without a second tool

Creative and agency

  • Columns: Briefing, Concept, Production, Sign-off
  • Rows per client or campaign
  • Contacts and tasks on one board

From briefing to client sign-off

Recruiting

  • Columns: Received, Screening, Interview, Contract
  • Rows per open position
  • Notes and appointments on the card

One pipeline per role

Overview

The state of every card at a glance.

A board only becomes a steering tool once everyone sees, without asking, where a task stands. That is exactly what the shared view delivers.

  • Every team member sees the status of every card, synced live through the cloud.
  • Per board a statistic shows the spread of cards by status, relevance or owner.
  • A standard status filter hides what does not count right now, such as archived cards.
  • Through the active statuses you decide which columns the team actually works with.

So the board is no weekly snapshot but a view that runs along with the work.

Intro call

Let's look at your workflow.

In 20 minutes we walk through which items belong on a board and how columns and rows map your status flow. You get a clear first read on whether teamspace fits how you work.

In a few steps

How a board comes about.

From an empty board to a running wall of columns is five steps, most of them one-off.

  1. 1

    Create the board

    Pick a type: Kanban, Scrum or pinboard. Each type starts with its own statuses and can be freely adjusted afterwards.

  2. 2

    Set columns and statuses

    Adjust statuses and decide what separates a column: status, owner, element type or group.

  3. 3

    Rows and colours

    Define the rows, for instance per person or client. Colour cards by status and choose the card size.

  4. 4

    Fill from the project

    Fill the board automatically or by hand from a project, a directory or a person, or place tickets and work packages straight on.

  5. 5

    The team drags the cards

    Everyone moves their cards through the statuses with the mouse. Hours are logged on the linked work package.

More from project management

Use cases that border on the board.

The board is one of several views on the same project. These areas go deeper into specific questions.

Scrum board

Sprint backlog and status columns for the sprint rhythm.

Learn more

Task management tool

Tasks with owners and due dates as a card source.

Learn more

Work breakdown structure software

Work packages that cards point to and book hours onto.

Learn more

Multi-project management

Many projects in parallel, each with its own boards.

Learn more

Project controlling

Plan vs actual and margin from the logged hours.

Learn more

Project documentation

Wikis and attachments, linked to the cards on the project.

Learn more

Choosing a method

When Kanban fits better than Scrum.

Kanban and Scrum are both agile methods; they differ in rhythm. Which one fits depends on the kind of work, and nobody has to commit for good.

  • Kanban works continuously. Cards flow as needed, and priorities can be reset at any time.
  • Scrum works in the beat of fixed sprints, with a binding sprint backlog and a sign-off at the sprint end.
  • teamspace runs both, as a kanban and a scrum board; the same work package switches view when needed.

You reach for Kanban when the work comes in continuously and is hard to plan. A support team cannot freeze a two-week plan when a critical incident lands today; it pulls the next card as soon as one frees up. When priorities turn faster than a sprint lasts, when tasks vary widely in size, or when the fixed sprint dates cost a small team more than they return, the open flow is the calmer route. Service, maintenance and operations therefore usually run better with Kanban.

A scrum board pays off where a product takes shape in plannable steps and a fixed delivery rhythm helps. What both boards deliberately do not bring are sprint analyses like burndown or velocity; they run freely configurable status columns, not measurement charts. Many teams use both side by side: development in the sprint beat, support in the running flow.

teamspace steering cockpit with three project rows, planned hours, a growing actual bar, a forecast marker, margin and a traffic light, one project on amber

In overview

The board is one view of project management.

Boards move items in an agile flow. How teamspace plans, steers and bills projects, from plan vs actual through earned value to the invoice from the project, is shown by the project management overview.

To project management

Intro call

Bring your backlog of work onto the board.

You show us your items and your status flow, and we align columns and rows to them. By the end you know whether teamspace fits how you work.

Frequently asked questions about the kanban board

What distinguishes Kanban from Scrum?
Kanban steers the continuous flow of tasks without fixed sprint timeboxes. Cards move from left to right as soon as capacity frees up. Scrum works in the beat of fixed sprints, with a sprint backlog and a sign-off. teamspace supports both on the same platform; kanban boards often suit service and maintenance teams, scrum boards development sprints.
What is a WIP limit?
In the Kanban method a WIP limit (work in progress) caps the number of cards that may sit in a column at once. It is meant to curb multitasking and surface bottlenecks. In teamspace you map columns and statuses freely; a WIP limit is an agreement in your team, not an automatism in the software.
Which elements can I put on a board?
Tickets, receipts, work packages, contacts, incoming invoices and notes can go on a board. They are real elements from teamspace, not copies. An element can sit on several boards at once, such as a service case on the support board and the project board.
How do we log hours on board cards?
A card that is a work package carries that package's link to the project. Staff log their hours on this work package, so they feed the project's plan vs actual and become billable. Cards and hours stay one item, rather than living apart in two tools.
Can we run several boards in parallel?
Yes. A separate board can exist per team, per project, per phase or per service area. Cards can be moved between boards, and an element can sit on several boards at once, for instance when a service case moves onto the project board.
What reporting does a board offer?
Per board a statistic shows the spread of cards by status, relevance or owner, as a pie chart. Through the standard status filter and the active statuses you steer what is shown. Sprint metrics like burndown or velocity the boards deliberately do not bring; they run status columns, not measurement charts.
Can we connect Kanban with the service desk?
Yes. Tickets from the service desk can be placed as cards on a board. A support team sees at a glance what is open, in progress and in test, and pulls the tickets onward as the state changes.
Where is the kanban data stored?
All data is processed in an ISO 27001 certified data centre in Frankfurt am Main, exclusively within the EU. teamspace is made in Germany and GDPR-compliant. The contracting party is 5 POINT AG, a German public company based in Darmstadt.