Backlog across all projects.
- Pick projects, subprojects or work packages
- Priority, relevance and time budget per card
- The whole picture, not a list per project
Scrum board: from the project backlog into the team's sprint.
In the teamspace scrum board you pull work packages from every project into one backlog, pace them into sprints and spread them across the team by capacity. They are real work packages: move a card and you move the project. Part of the teamspace cloud software.
Agile project management
Scrum is built into project management.
You use Scrum in teamspace without a second tool. The method runs straight inside project management, on the same projects and work packages you already plan and bill with. In three steps, each with its own view, you gather requirements in the product backlog, spread them across sprints in the sprint log and work through them in the sprint. That way an agile team keeps its rhythm, and every card stays a real work package from the project.
Starting point
When every project plans its own sprint.
- Each project plans for itself, the picture across the week is missing
- In the sprint it is unclear who still has capacity and who is overloaded
- Tasks live in one tool, the hours in another
- What was billable only surfaces at month end
A sprint that holds real work packages, capacity and billing together takes the stress out.
The principle
Three steps from backlog to sprint.
teamspace runs Scrum in three steps, each with its own view: first the backlog drawn from every project, then the spread across weekly sprints, last the sprint where everyone works through their packages.
1 · Backlog all projects
Website-Relaunch WP-1.4 selected
M365-Migration WP-2.3 selected
Mobile App WP-5.1 ·
Packages for the quarter
2 · Sprint log in cadence
CW 21/22
CW 23/24
CW 25/26
active sprint CW 23/24
3 · Sprint per person
LK Lena K. 32 / 40 h
Onboarding flow
JB Jonas B. 24 / 40 h
API integration
assigned until capacity is full
Many projects become one person's sprint, planned in real hours rather than abstract points, on real work packages.
Step 1
The backlog forms from every project.
A backlog does not start from zero. This step has its own view, where you pick from the whole project stock what should come up over the next few weeks.
- Whole projects, any subprojects or single work packages drag into the backlog, across projects.
- Per project the view separates what sits "in the backlog" from what is still out, by drag and drop.
- Every card shows priority, a star relevance and its time budget in hours.
- So you see the picture across all projects, not just a list per project.
The backlog often takes shape in a wider frame, say a release plan that runs across the quarter. Many separate project plans become one shared stock list from which the sprints are filled.
Feature set
What sprint planning brings.
Sprints on a weekly cadence.
- Sprints by calendar week, with an active sprint
- Backlog packages dragged into the sprint
- The scope holds for the sprint duration
Capacity and billing.
- Packages per person, until capacity is full
- A column of its own for billable work
- Hours run into the project, not a separate tool
Step 2
In the sprint log the backlog gets a cadence.
The backlog says what is due. The sprint log says when. On a working surface of its own you spread the packages across concrete sprints, paced by calendar week.
- Side by side sit the backlog and the coming sprints, say CW 21/22, the active CW 23/24 and CW 25/26.
- You drag a package out of the backlog into the sprint it should be finished in.
- The sprint length is fixed and configurable, say two weeks; usually you plan only the next sprint.
- What a sprint does not finish stays in the backlog and moves into the next one.
A large stock list becomes manageable packages for a sprint of fixed length, with a clear start and end.
“Staff in both support and project planning can see orders and invoices. That was not possible before.”
Step 3
In the sprint, each person's capacity counts.
The sprint itself is organised by person. Here you assign work packages to each person, until their capacity for the sprint is full. Then it is over to them: do the assigned work and make it visible through the status.
- Per person, a bar shows how much of the available hours is already planned in.
- Every package starts as planned. The person drags it on, through In progress, To hand over and Billable to Done.
- Instead of whole people you can also plan with staff groups.
- Hours logged run through the work package into the project's plan vs actual.
So nobody plans past the limit: whoever is full is visibly full, and the next card goes to someone with room.
Intro call
Let's look at your sprint planning.
In 20 minutes we walk through your path from the project backlog over the weekly sprint to capacity. You get a clear first read on where teamspace fits in your sprint.
Method
What Scrum actually is.
A scrum board is the working surface of a team that works in fixed time slices. Requirements gather in a backlog; for each sprint, usually one to four weeks, the team pulls out a selection and brings it to acceptance by the sprint's end. The term comes from rugby, where "scrum" means the ordered tussle for the ball.
Three things carry the method, whatever the tool:
- A fixed cadence: a sprint has a start and an end. What was chosen into it stays stable for the duration, rather than shifting day by day.
- Selecting instead of everything at once: only as much enters the sprint as the team can realistically finish in the time.
- Something to show at the end: by the sprint's close there is something accepted that can be discussed and shown to customers.
In teamspace you map this method onto real project work packages, from the cross-project backlog over the weekly sprint to the load on each person. A board online rather than at the whiteboard has two hard advantages: distributed teams work on the same footing, and every card stays a real element from the system.
Why this way
Real hours instead of abstract points.
teamspace plans sprints not in estimate points but in what projects already carry: hours, capacity and billability.
Planned in hours
- Every package has its time budget in hours
- No converting points into days
- Comparable with plan vs actual
Capacity in view
- Per person, you see how full the sprint is
- Assign until capacity is reached
- Works for staff groups too
Billable kept apart
- A column of its own for billable work
- Hours flow into billing
- Margin on fixed price in view
Choosing a method
Kanban or Scrum? Both run here.
The difference sits in the rhythm, not the tool. A development team that thinks in releases does better with sprints; a support team with fresh cases arriving daily does better with a running flow.
- Scrum bundles work into fixed sprints and accepts it at the sprint's end. Strong when releases should be plannable.
- Kanban pulls each card through on its own as capacity frees up. Strong for service and maintenance.
- In teamspace both sit side by side, and the same work package switches view when a team switches method.
One thing you should know: analytics like a burndown chart or a velocity figure are not part of it. A board shows status in columns, not a sprint chart. Starting at the backlog stack and the time logging gets you further in practice than the next curve.
More from project management
Use cases around the board.
Around the sprint sit further areas of project management. Each of these goes deeper on one question.
Kanban board
A continuous task flow without fixed sprint windows.
Learn moreCapacity planning
Who carries how much sprint load, reckoned across every project.
Learn moreWork breakdown structure software
Work packages that move onto the sprint as cards.
Learn moreMulti-project management
Many projects in parallel, one shared backlog.
Learn moreProject controlling
Plan vs actual and margin from the logged sprint hours.
Learn moreProject billing software
Billable work from the sprint into the invoice.
Learn moreIn the sprint
How a package moves through the sprint.
Within a sprint every work package runs the same five stations, from planning to done.
- 1
Planned
The package is assigned to a person but not yet started.
- 2
In progress
The person drags the card and logs their hours on the work package.
- 3
To hand over
The work is finished and waiting for a check or review.
- 4
Billable
Accepted work is marked as billable and goes into billing.
- 5
Done
The package is finished, the hours sit on the project.
At a glance
The sprint is one view of project management.
Boards move items in an agile flow. How teamspace plans, steers and bills projects, from plan vs actual over earned value to the invoice from the project, the project management overview shows.
To project managementRelated modules
Three modules dock straight onto the sprint.
Whoever moves packages in the sprint almost always deals with the hour, the invoice and the contact. Here are the shortest routes there.
Time tracking
Hours land on a card's work package and are the basis for plan vs actual and billing.
- Log on project, phase or ticket
- Billable or internal kept apart
- Approvals stay traceable
Invoicing software
Accepted work becomes the invoice, with hourly rates, flat rates and billing rules.
- Partial, progress and final invoices
- ZUGFeRD and XRechnung
- Hand-off to DATEV
CRM software
Contacts of a campaign sit as cards in the sprint and stay linked to the customer file.
- Contacts and tasks on one board
- Customer file on the live item
- Shared data, no double upkeep
Intro call
Bring your sprint onto the board.
Show us your projects and your sprint cadence, and we align backlog, sprints and capacity to them. By the end you see whether the teamspace sprint cadence suits your team.
Frequently asked questions about the scrum board
How does the backlog form in the scrum board?
You pick from every project what is due, whole projects, subprojects or single work packages, and drag it into the backlog, say for a quarter. Per project the board separates what sits in the backlog from what is still out. So you plan across projects, not in separate lists.
Which columns does the sprint have in teamspace?
In the sprint the cards move through five columns: Planned, In progress, To hand over, Billable and Done. These statuses can be adjusted, as can the whole configuration. The backlog and sprint log are separate views before it, where you select and pace into sprints.
How does the spread by capacity work?
The sprint is organised by person. You assign work packages to each person, and a bar shows how much of the available hours is already planned in, until capacity is full. Instead of single people you can also plan with staff groups.
Does the board bring burndown or velocity?
No. teamspace plans sprints in real hours and capacity, not in abstract story points. The board runs status columns, not measurement charts. Sprint analytics such as burndown charts or a velocity calculation are deliberately not part of the board.
What sets Scrum apart from Kanban?
Scrum works on a cadence of fixed sprints, with selection into the sprint and acceptance at the sprint's end. Kanban steers the continuous task flow without fixed windows. teamspace supports both on the same system; often scrum boards suit development sprints and kanban boards suit service and maintenance teams.
Does the sprint work on real work packages?
Yes. A card is the real work package from the project, not a copy. Drag it to another column or to another person and you change the real item. The hours logged on it run into plan vs actual and become billable.
Can we run several scrum boards in parallel?
Yes. Per team, department or product a scrum board of its own can run with backlog, sprint log and sprint. Someone caught up in several of these processes can additionally show a personal sprint board that bundles their work packages from different departments in one place.
Where is the scrum 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.