The Shared-Owner Sprint Planner: A Week-by-Week Worksheet for Scheduling Two Concurrent Projects Around One Person

Published 2026-09-27 13:14 KST

You're setting up a three-week sprint. You open the task list for Project A, then the task list for Project B, and you notice the same name on both. Neither plan mentions the other project. Neither plan shows a conflict.

That's the gap this worksheet is designed to close.

The goal is simple: lay both sprints side by side, week by week, before work begins. Find the exact tasks where that shared person is expected to be in two places at once. Then decide what to do about it now, while you still can.

Why the conflict stays hidden until it hurts

Sprint plans are usually written one project at a time. Project A gets its own doc, its own board, its own owner column. Project B gets the same. Neither document has a column that asks "what else is this person doing this week?"

So the double-booking doesn't show up during planning. It shows up on a Tuesday in week two, when the shared owner has a deliverable due on both projects and no one planned for that.

Some practitioners discuss this kind of hidden cross-project load as a coordination problem that's easy to miss precisely because each project looks fine on its own — it's only when you place them side by side that the overlap becomes visible (see a practitioner discussion about cross-team dependencies).

The fix isn't complicated. It just requires putting both plans in the same table at the same time.

Before you fill in the worksheet

Gather three things:

• Project A task list — the tasks planned for the three-week window, with a rough estimate of effort in days for each task, and the owner's name.
• Project B task list — the same information for the second project.
• The shared owner's existing commitments — any meetings, reviews, or other obligations already on their calendar during the sprint window. Even a rough picture helps.

You don't need perfect estimates. A rough number of days per task is enough to see where the load piles up.

The worksheet: filled example

The table below shows a fictional three-week sprint. The shared owner is a developer named Jordan. Project A is a backend API update. Project B is a data migration. Both projects listed Jordan as an owner without checking the other.

Read through the filled example first. The blank version follows immediately after.

Three conflicts surfaced. Each one got a decision before the sprint started. Jordan's week is no longer a mystery to either project lead.

What the conflict flag is actually telling you

A "Y" in the conflict column means the shared owner's estimated days for both projects in that week add up to more than the working days available, or that two high-priority tasks land on the same day.

It doesn't mean the sprint is broken. It means you have a choice to make now rather than later. There are three basic moves:

• Split the week. If both tasks are small enough, the shared owner can do one in the first half of the week and the other in the second half. This works when neither task requires deep, uninterrupted focus across multiple days.
• Reassign one task. If someone else on the team has the skill and the capacity, move one of the conflicting tasks to them. Confirm their availability before you write it into the plan.
• Move a deadline. If neither task can be reassigned and splitting the week isn't realistic, one task needs to slide. Decide which project absorbs the delay before the sprint begins, not after a missed deadline forces the conversation.

You might also find that the conflict is smaller than it looks once you check the calendar. A task estimated at three days might only need the shared owner for one of those days. The worksheet gives you the place to write that down and make it visible.

The blank worksheet — copy and fill in

Copy this table into any document, spreadsheet, or planning tool you already use. Fill in one row per task that involves the shared owner. Leave the project column blank for any week where that project has no task for this person.

Add as many rows per week as you need. If you have more than one shared owner across the two projects, run a separate table for each person.

A few things to check as you fill it in

Check the calendar before you estimate. If the shared owner has a two-day offsite in week two, that week has fewer working days than it looks. The conflict flag should account for real available days, not a theoretical five-day week.

Watch for back-to-back context switches. Even when the math works — say, two days on Project A and two days on Project B in the same week — switching between two very different kinds of work takes time to settle. If both tasks require deep focus, splitting them across the week is gentler than alternating daily.

Write the resolution decision in plain language. "TBD" is not a resolution. The column should say who is doing what, or which deadline is moving, and who agreed to it. If you can't fill in that column, the conflict isn't resolved yet.

Share the table with the shared owner. They're the person most affected by the plan. Showing them the table before the sprint starts gives them a chance to flag anything you missed — a dependency, a meeting, an estimate that's off — while there's still time to adjust.

What to do if you find more than three conflicts

If the conflict column has a "Y" in most rows, the problem isn't scheduling — it's that the shared owner has been assigned too much work across both projects for the sprint window to absorb.

At that point, the worksheet has done its job. It's shown you the shape of the problem clearly. The next step is a conversation with both project stakeholders about which project has priority, or whether the sprint scope needs to change before it starts.

That conversation is easier to have before the sprint than during it.

Where this fits in a broader planning picture

This worksheet covers a bounded three-week window for two projects. If you're managing more than two concurrent projects, or you want to map conflicts across a longer horizon, the Multi-Project Conflict Spotter extends the same side-by-side logic across a wider view.

If you filled in this worksheet and realized the shared owner was assigned without anyone checking their existing load, the Capacity-Aware Meeting-to-Execution Worksheet walks through how to catch that earlier in the planning process.

And if the shared-owner conflict you found is also a dependency that crosses team boundaries — where Project B can't proceed until Project A's owner finishes something — the Dependency Timeline Stress-Test helps you check whether the dates on both sides of that dependency are realistic.

How Tindlo can help surface this earlier

One reason shared-owner conflicts stay hidden is that the two project plans live in separate places. You can't see Project A and Project B on the same view at the same time, so the overlap never becomes obvious until someone misses something.

Tindlo is built around a shared time axis where different projects, teams, and work types sit in parallel layers. When you're planning a sprint, you can see both projects alongside each other in the same week view. And because Tindlo connects to Google Calendar, the shared owner's existing calendar commitments — meetings, reviews, time already blocked — are visible in the same place as the sprint tasks.

That combination makes it easier to spot a double-booking during planning, before it becomes a blocker mid-sprint.

If that kind of visibility would help your planning process, you can try Tindlo and see how it fits your workflow.

The short version

When the same person appears on two concurrent sprint plans, neither plan shows the full picture on its own. The worksheet in this article gives you a single table where both plans sit side by side, week by week, with a column for the conflict and a column for the decision.

Fill it in before the sprint starts. Share it with the shared owner. Make the resolution decisions while you still have room to move things around.

That's the whole idea.