Looking for a Jira Cloud mentor for DevOps program management, capacity planning, and demand intake

Question

I’m starting a new role as a DevOps Transformation Program Manager and I’m looking for practical guidance from someone experienced with Jira Cloud in engineering/DevOps environments.

I am not trying to become a Jira administrator. My goal is to become very strong at using Jira to support:

* demand intake
* capacity visibility
* BAU vs reactive vs project vs transformation work
* backlog management
* prioritization and tradeoffs
* dependencies
* sprint/flow planning
* JQL
* dashboards
* executive reporting
* roadmap visibility

I learn best through hands-on scenarios rather than generic tutorials.

For example, I’d like to work through situations such as:

* a CloudOps manager says the team has no capacity, but Jira appears to show only 50% allocated
* a large amount of engineering work is coming through Slack, meetings, incidents, and ServiceNow rather than Jira
* leadership wants a new priority added, but the team is already fully committed
* we need to distinguish planned work from reactive work and understand the real impact on capacity
* we want to create a lightweight intake and prioritization model without making engineers feel over-managed

I have created a small Jira Cloud sandbox where I can build sample data and practice.

I’d be very interested in connecting with someone who has experience using Jira Cloud with DevOps, Platform Engineering, CloudOps, or SRE teams and who would be open to a few 1-on-1 mentoring/coaching sessions.

What would you recommend I focus on first, and are there experienced Atlassian practitioners in the community who provide this type of mentoring?

I’m intentionally keeping the examples generic because this is a public forum.

Josh · Answer

Hi Jay, I can't offer 1-on-1 sessions here, but your first scenario is the best place to start, so here's how I'd work through it in your sandbox.

"The team says no capacity, Jira shows 50%." Both are usually true. Jira is showing estimates on assigned work items, while the team is feeling time actually spent, including interrupts that never became work items. To make the gap visible:

* Add a required Work category select field (BAU / Reactive / Project / Transformation) on create. Have an Automation rule default incidents and anything created from Slack or email to Reactive.
* Ask the team to log time for two weeks, even roughly. Then compare assignee in membersOf("cloudops") AND worklogDate >= -14d (actual effort) against assignee in membersOf("cloudops") AND sprint in openSprints() (planned). Use Σ Time Spent vs Σ Original Estimate columns in list view.
* Put a Two Dimensional Filter Statistics gadget (Assignee × Work category) on a dashboard. The Reactive column is usually the missing 50%.

Work arriving through Slack, meetings, incidents and ServiceNow. Make capture cheaper than bypassing Jira. Atlassian's Jira Cloud for Slack app lets people create a work item from a message in two clicks. One intake form or request type, with 4–5 fields maximum, covers the rest. Don't gate it with approvals at first. Just get it counted.

"Leadership adds a new priority." Keep one ranked backlog per team and show the cut line against capacity (Plans can do this per sprint on Premium). Then ask "what drops below the line?" That turns the conversation into a trade-off instead of a bigger commitment.

Order I'd learn it in: intake + Work category first, JQL second, dashboards third, Plans/dependencies last. Capacity numbers are only as good as the capture.

For the capacity piece specifically: the native gadgets give you counts and estimate totals, but not a per-person weekly view of expected vs actual hours. Aneto Hours Reports and Resource Planner shows capacity next to time spent by person and project from the worklogs, which is exactly the "50% vs full" conversation.

Disclosure: I work at Aneto Software, which makes this app.

Hempel · Answer

Welcome to the Atlassian community!!

Jovânio Junior · Answer

Hi there – Welcome to the Atlassian Community!

I’d start with work visibility before capacity. If work is still coming through Slack, meetings, incidents, and ServiceNow without consistently landing in Jira, any capacity view will be misleading.

A practical learning path would be:

define a simple work taxonomy such as BAU / Reactive / Project / Transformation;
create a lightweight intake model so meaningful work enters Jira consistently;
use JQL to compare planned vs. unplanned work, ownership, aging, and priority;
then build dashboards around capacity, backlog health, delivery risk, and executive tradeoffs;
finally move into dependencies and roadmap/Plans once the underlying data is trustworthy.

For your sandbox, I’d recreate exactly the scenarios you listed. For example, build a team with 100 hours of apparent capacity, deliberately leave 30–40 hours of reactive work outside Jira, and then model what happens when leadership adds another priority. That will teach you much more than feature-by-feature tutorials.

One important lesson in DevOps environments is that Jira should help make tradeoffs visible, not become another layer of administration for engineers.

And yes, there are experienced Atlassian practitioners who provide consulting, training, and coaching. The Atlassian Partner Directory is a good place to find Solution Partners with relevant consulting or DevOps experience.

If you find someone for mentoring, I’d specifically look for experience with Platform Engineering, SRE/CloudOps, capacity planning, and executive reporting, rather than just Jira administration.