Teambook for IT & Software Teams

How engineering teams use Teambook for realistic sprint planning?

Sprints often fail not because the code is hard, but because the "100 hours of capacity" you thought you had was actually 60 due to a bank holiday, a sick leave, or a dev being pulled into a high-priority bug fix on another project.

Teambook bridges the gap between your Jira/DevOps backlog and the actual human beings doing the work.

Step 1: Set a realistic baseline capacity

Before pulling tickets into a sprint, you need to know how much time your team actually has available.

In Teambook:

Set each developer’s working schedule in their user profile.
Let Teambook automatically factor in:
- Public holidays
- Part-time contracts
- Planned time off
Set realistic utlization rate, for example:
- 85% is a usually accepted target
- meaning that 15% is spend on non-productive tasks

This gives you a true baseline capacity, not a theoretical one.

Step 2: Spot overcommitment before the sprint starts

Use the User View in the Planning module to immediately spot availabilities (any cell in white) and overscheduling (red figures)

When someone turns red, you can immediately:

Reassign work to a developer with available capacity simply by dragging & dropping the concerned bookings to another user (you may want to filter the list by skills / tags)
Reduce the scope or duration of a task
Push work to the next sprint simply by dragging & dropping the concerned bookings to a later date

This replaces the spreadsheet habit of noticing overload only after the sprint has already failed.

Step 3: Protect time for “business as usual” work

IT & Software teams always have invisible work like daily standups, code reviews, internal meetings or unplanned hotfixes.

If you ignore this, your velocity will always be overstated.

Best practice in Teambook:

Create Internal projects (set them as non-billable)
Book a fixed amount of time per developer, for example 1 hour per day, assigned to the appropriate internal projects. Use recurring bookings for that purpose

This ensures sprint capacity reflects actual coding time, not total working hours.

Step 4: Run a post-sprint reality check

At the end of the sprint, ask your colleague to fill-in their Timesheets. Once done compare planned vs. actual time in Reports.

What to look for:

Planned 40 hours, tracked 30 hours = capacity or estimation gap
Repeated gaps across sprints = structural issue, not a one-off

How to use this:

Bring the data into sprint retrospectives
Adjust story point estimates or workload assumptions
Refine BAU allocations if needed

Over time, this turns sprint planning from guesswork into a feedback loop.

What success looks like

Teams using Teambook for sprint planning typically see:

Fewer missed sprint commitments
More predictable velocity
Earlier detection of overload
Better trust between product, engineering, and stakeholders

Sprint plans become something the team can actually deliver, not something they hope will work.

What to do next

To make sprint planning more reliable going forward:

Review each team member’s working schedule and allocations to ensure they reflect reality, not assumptions
Create nternal projects to book non productive hours and apply such bookings consistently across all sprints
Use the User View during sprint planning to resolve overcommitment before the sprint starts
Review planned vs. actual time at the end of every sprint and adjust capacity assumptions regularly

Used consistently, this approach helps teams plan based on real availability instead of optimistic estimates.

If you need help setting up projects, personal scheduoles or reports, contact support and we can help you configure sprint planning workflows in Teambook.