They committed to 60 engineers’ worth of work with 35 engineers
What happens when capacity planning runs on spreadsheets, and how live data changes the math.
Overcommitment rarely starts with bad intent. It starts with optimism and limited visibility.
When Jensen Fleming, a Principal Product Manager at Atlassian, realized her team had effectively overcommitted, the issue wasn’t ambition, it was math. “We’ve committed to the work of 60 engineers, but we’re a team of 35,” she says.
There was no buffer for emergencies, no reliable view of when anything would ship, and no data to back up a polite “not yet” when new requests rolled in. Something had to change.
Here’s how Jensen used Jira Product Discovery (JPD) to bring the math back into the conversation.
The spreadsheet that died every two weeks
Like many before her, Jensen tried a Google spreadsheet. She’d list all the projects, plug in dates, assign engineers, and feel organized for about two weeks. Then dates would shift, new projects would appear, and someone would forget to update a row. “It was so much work to repeat every two weeks,” she says.
This was frustrating and costly. She had to rebuild the spreadsheet and chase down updates before she could plan what came next.
Building a capacity view that stays alive
About four months before the webinar, Jensen built a dedicated capacity planning view inside Jira Product Discovery. She described it as “a spreadsheet in JPD,” but unlike the old version, it pulls from live project data and stays up to date.
Here’s how she structured it:
Split by engineering team. Jensen works with two teams: Quakus and Ragents (short for Rovo Agents). Each has its own section in the view, with separate tracking for workstreams.
Monthly engineer columns. For each project, she enters the number of engineers needed per month. These columns feed into calculated roll-up fields that show total committed capacity per period.
A “yes/no” resourcing column. If the monthly engineer columns are populated, the project is resourced and gets a “yes” If not, it sits in the “no” column.
A hard capacity target. Each team has a known headcount. Quakus has 11.5 engineers available per month. Ragents has 12. The roll-up metric needs to stay at or below that number.
When Jensen first built the view, the number was sitting at 18.
This meant they needed to reprioritize work that already felt committed. Projects that had seemed reasonable on their own were now competing for the same limited capacity. The data made the tradeoffs visible and harder to sidestep.
So, they had to shift the conversation. Instead of debating whether the team was overextended, they debated which work mattered most.
What the data revealed
One pattern the capacity view exposed immediately was the front-end constraint. Out of 35 engineers, Jensen’s team has only four or five front-end developers.
To manage this, she created a companion view: a front-end roadmap using a timeline layout, grouped by engineer. Each engineer’s projects appear as bars on a timeline, making it visually obvious who’s overloaded and who has bandwidth.
“Andy’s working on three things. Ben’s working on two. Ivan’s working on too many things, but that’s Ivan’s vibe – he’s really fast, so it works,” she says.
At the bottom of the timeline sits the backlog. These are projects that need front-end work but aren’t yet assigned. When someone finishes a project, the team can drag a backlog item into their lane. The dates auto-adjust and the engineer is reassigned. No manual spreadsheet gymnastics.
The view is especially useful in Andy’s weekly front-end syncs. Instead of debating what to prioritize, the team can see who has capacity and assign the next item accordingly.
Beyond team-level capacity, Jensen uses a per-engineer timeline view to see exactly how many projects each person is juggling. At one point, it showed a single engineer assigned to nine different initiatives.
That kind of overload is easy to miss in a grid. Grouped by person on a timeline, it’s immediately visible and easier to fix.
From gut feel to evidence
Jensen didn’t originally set out to use Jira Product Discovery for capacity planning. “I don’t think I ever imagined I could do that in JPD,” she says. “But I’ve become so obsessive with it that I started trying to do everything in there.”
The team assesses the view once a month. Because it’s built on live data – the same fields, dates, and assignments they use every day – it stays current without a spreadsheet to rebuild.
The real shift shows up when new requests come in. Instead of relying on gut feel, they can point to the numbers and show exactly when capacity opens up.
If you’re still planning in spreadsheets, start here
Jensen’s approach is worth borrowing:
- List your active projects in Jira Product Discovery. Tag the engineers working on each one and add start and end dates.
- Add monthly engineer columns. Use calculated fields to roll up the total committed engineers per period.
- Set your capacity ceiling. How many engineers do you actually have? Compare the roll-up against that number.
- Create a timeline view by engineer. Switch to a visual layout to spot over-allocation that grid views hide.
- Keep a “not resourced” section. Items without dates go here. It’s your pull list for when capacity opens up.
Capacity planning without live data doesn’t scale. When commitments live in static spreadsheets, overcommitment creeps in quietly until the gap between work and headcount becomes impossible to ignore.
Once Jensen’s team could see their true capacity in real time, the conversations changed. Tradeoffs became explicit, promises became credible, and overcommitment stopped being a surprise. That’s the difference between planning by optimism and planning by evidence.
Want clearer visibility into your team’s true capacity? Try Jira Product Discovery today to see how live data turns planning from guesswork into evidence.