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.
Reflect real allocations, for example:
- 80% on Product work
- 20% on Maintenance or Support
Let Teambook automatically factor in:
- Public holidays
- Part-time contracts
- Planned time off

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

Step 2: Spot overcommitment before the sprint starts

Use the User View while planning.

Each team member has a visual capacity bar:

Green means available
Red means over capacity

When someone turns red, you can immediately:

Reassign work to a developer with available capacity
Reduce the scope or duration of a task
Push work to the next sprint

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

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

Engineering 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 a recurring BAU or Internal project
Book a fixed amount of time per developer, for example 1 hour per day

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, 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 a standard BAU or Internal project and apply it 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 capacity rules, BAU projects, or reports, contact support and we can help you configure sprint planning workflows in Teambook.