PTO Tracking and Capacity Planning: Stop Overbooking Your Team

Sprint planning typically starts with a question: "How many story points can we commit to this sprint?" The answer depends on who is available. And who is available depends on who has approved time off during the sprint window.

In most teams, these two pieces of information live in different systems. Sprint planning happens in Jira. PTO tracking happens in a spreadsheet, an HR tool, or someone's memory. The connection between them is a human being who remembers to check both before committing to a sprint scope.

When that connection fails, the result is overcommitment. The team plans for full capacity, then discovers mid-sprint that two engineers are out for three days each. That is six person-days gone, and the sprint scope does not shrink to match.

The math behind capacity planning

Capacity planning is straightforward arithmetic, but only if you have the inputs.

A standard two-week sprint has 10 working days. A five-person engineering team has a maximum capacity of 50 person-days. But that is the theoretical maximum. Real capacity is lower:

• Subtract public holidays (if the sprint overlaps with a holiday, everyone loses that day)
• Subtract approved PTO (individual absences)
• Subtract recurring non-sprint work (on-call, meetings, support rotation)

If one engineer is out for three days and a public holiday falls in the sprint, actual capacity is 44 person-days, not 50. That is a 12% reduction. Planning at 100% and delivering at 88% is a recipe for missed commitments.

Why PTO data stays disconnected

The reason PTO and capacity planning are separate is usually historical. When the team was small, everyone knew when everyone else was out. There was no need to formalize it. As the team grew, PTO tracking moved to a spreadsheet or an HR tool, but sprint planning stayed in Jira. Nobody built the bridge.

The consequences:

• Sprint planning relies on tribal knowledge. "Is anyone out next week?" is asked verbally at the planning meeting. If someone forgets to mention their Wednesday off, the plan is wrong.
• Managers double-check absences manually. They look at the PTO spreadsheet, cross-reference with the sprint dates, and mentally adjust capacity. This works until it does not.
• Leave requests approved without context. A manager approves a PTO request without realizing it overlaps with a sprint that has a hard deadline. The team finds out too late to adjust.

Connecting the two systems

There are three ways to bring PTO data into sprint planning.

Option 1: Manual capacity spreadsheet

Before each sprint planning session, the scrum master builds a capacity spreadsheet. They check the PTO tracker, note who is out, subtract days, and present the adjusted capacity to the team.

This works but does not scale. It takes 15 to 30 minutes per sprint, it depends on a single person doing it correctly, and it is outdated the moment someone submits a new PTO request after the spreadsheet was built.

Option 2: PTO issues on the Jira board

Some teams create "Out of Office" issues in Jira so absences are visible alongside sprint work. This makes PTO visible during planning, but at the cost of cluttering the board with non-work items.

Option 3: Integrated leave and availability data

The ideal approach is leave data that lives in the same tool as sprint planning, visible without manual effort. When a manager opens the sprint planning view, they see: five engineers on the team, one is out Monday and Tuesday, actual capacity is 48 person-days. No spreadsheet, no Slack thread, no guesswork.

This requires leave tracking to be built into (or tightly integrated with) your Jira instance. TeamOps provides this by running leave management inside Jira. Approved absences show up in a team availability view, and managers can see who is out during any date range.

Leave approval with capacity context

The other half of this problem is leave approval. When a manager approves a PTO request, they should know the impact on team capacity. If three of five engineers request the same Friday off, approving all three means the team is at 40% capacity that day.

Without visibility, the manager approves each request in isolation. They do not realize the overlap until the sprint is already planned and someone points out that half the team is gone next Friday.

A leave management system with team-level visibility surfaces this conflict at approval time, not at planning time. The manager sees: "Approving this request means 3 of 5 engineers are out on June 14th." They can still approve it, but they are making an informed decision.

Seasonal patterns and forward planning

PTO data is not just useful sprint-to-sprint. Aggregated over time, it reveals seasonal patterns that inform quarterly planning.

• December holidays: Most teams lose 30 to 40% of capacity in the last two weeks of December. Planning a major launch for December 20th is planning for failure.
• Summer Fridays: June through August PTO usage spikes, often on Fridays. If your team runs four-day weeks in summer, plan accordingly.
• Q1 carryover surge: Employees who carried over unused PTO from the previous year tend to use it in Q1. January and February capacity is often lower than expected.

These patterns are only visible when you have historical PTO data in a queryable system. A spreadsheet can technically do this analysis, but few teams actually do it. An analytics layer that shows PTO trends by month makes the pattern obvious.

A practical workflow

If you want to connect PTO tracking and capacity planning today, the simplest path is:

1. Move leave tracking into Jira using a purpose-built leave app so absences are in the same system as your sprint board.
2. Check team availability before sprint planning. Look at approved absences during the sprint window and calculate actual capacity.
3. Scope the sprint to actual capacity, not theoretical. If capacity is 88%, plan for 88%.
4. Review PTO trends quarterly. Identify months with historically lower capacity and adjust delivery expectations accordingly.