Best approach for Sprint Planning visibility in Jira Service Management (Data Center)

[Namrata Bhomkar]

Hi everyone,

We're using Jira Service Management (Data Center) integrated with a Jira Software project. Our development team performs sprint planning and development work in the Jira Software project, while customers raise and track requests through JSM.

Our team would like customers to have better visibility into when their requests are expected to be worked on.

Initially, we considered exposing sprint information, but we realized that customers won't understand labels like Sprint 1, Sprint 2, etc., and exposing sprint details may not provide meaningful information to them.

We're looking for best practices on how to achieve this.

Some questions we have:

• Is it recommended to use sprint planning directly in Jira Service Management, or should all sprint planning remain in the linked Jira Software project?

• What is the best way to communicate to customers when their tickets are expected to be addressed?

• Has anyone implemented fields such as Planned Release, Target Date, Expected Start Date, or another customer-friendly status instead of exposing sprint names?

• Is there a recommended approach in Jira Data Center that provides customers with useful timeline information without exposing internal sprint planning?

Our goal is to keep sprint planning internal for the development team while giving customers realistic and understandable expectations about when their requests will be worked on.

I'd appreciate hearing how others have solved this problem and what approach has worked best in production environments.

Thanks!

[Yuri Lapin _Release Management_]

Hi @Namrata Bhomkar,

Good question.

You typically develop in sprints, but you don't necessarily deliver by sprint. A work item being completed in a particular sprint doesn't automatically mean it has been released to customers, so I wouldn't mix the two concepts.

This is how we handle it internally:

• For every Change Request (CR) in Jira Service Management, we automatically create an internal development issue in Jira Software. That work may span multiple teams, sprints, and projects.
• We use Jira Releases across Jira Software and Jira Service Management, orchestrated through our Release Management app—so yes, we eat our own dog food. 🙂
• As releases progress through their workflow towards production, automation updates the corresponding CR status and Target Release Date, ensuring stakeholders always have an accurate view of delivery progress.

We find this approach provides a much clearer separation between delivery planning (sprints) and customer-facing releases, while maintaining full traceability between the two.

Hope this helps!

Cheers,

Yuri

[Mary from Planyway]

Hi @Namrata Bhomkar 

I would keep sprint planning in the Jira Software project and use Jira Service Management purely as the customer-facing intake and communication layer. Sprints are an internal execution mechanism, and exposing names such as “Sprint 14” rarely gives customers a useful expectation.

IMHO, a practical setup would look like this:

1. Create or link a Jira Software delivery issue for each request that requires development.
   The JSM request remains the customer record, while the linked Story, Bug, or Task is what the development team estimates, schedules, and moves through sprints.

2. Plan the delivery issues in Planyway.
   Create a Planyway workspace connected to the Jira Software board, or use a saved JQL filter containing only customer-related development issues. Planyway can combine multiple Jira projects, display sprints and releases internally, and synchronize scheduled start and end dates with Jira fields. It also supports Jira Data Center.

3. Map the Planyway dates to customer-friendly Jira fields.
   For example:

   • Expected Start

   • Target Delivery

   • Delivery Forecast: Under review / Planned / Scheduled / In progress / Released

   • Last Forecast Update

   • Optionally, Planned Release as a text or select-list field

   I would label the dates as forecasts rather than commitments and only populate them once the work has been reviewed and capacity-planned.

4. Copy the forecast back to the JSM request.
   Use Jira Data Center automation so that when the dates or delivery stage change on the linked development issue, the corresponding fields on the JSM request are updated. Jira Data Center automation supports editing fields and working with linked issues.

5. Present only the simplified information to customers.
   The development team can still see the sprint, assignee, dependencies, workload, and detailed Planyway roadmap. The customer sees something like:

   Delivery stage: Scheduled
   Expected start: August 10
   Target delivery: August 28
   This is the current forecast and may change if priorities or dependencies change.

I would avoid exposing the native Fix Version or Sprint fields directly. In Jira Service Management Data Center, date pickers, select lists, and text fields are supported on customer request types, while fields such as Version Picker and Linked Issues cannot be made visible on the customer portal. A separate customer-facing release field is therefore usually easier to understand and configure.

In production, I would start with a delivery stage plus a target delivery window rather than publishing precise dates too early. Once the issue is committed to a sprint and capacity has been validated in Planyway, the forecast can become more specific.

[Alex David]

Hey Namrata, short version, keep the sprint planning in the Software project and translate it into something customer-friendly on the JSM side rather than trying to plan in the service project.

On your first question there isn't really a choice to make on Data Center. Boards for Jira Service Management is a Cloud only feature, so on DC there's no native way to turn sprints on inside a service project. The workaround people use is a board in a Software project scoped by a JQL filter that pulls the JSM issues in. Worth being upfront that this doesn't remove the split you're describing, your agents still work two surfaces, the queue and SLA view on one side and the board on the other.

The thing I'd be most careful about is keeping the SLA separate from the delivery date. If the SLA stop condition ends up tied to the dev work finishing, every roadmap slip becomes an SLA breach, and people start fudging transitions to keep the breach numbers clean. Let the SLA measure response and triage, which is what your team actually controls, and treat the delivery date as a separate roadmap commitment that nothing is measured against.

On communicating the timeline, both fields you mentioned work, with different trade-offs:

- A custom Target date or Planned release field on the request is the more controllable option. You own the wording and the granularity.

- Fix Version is tempting since it already exists, but two things bite. Version names are usually internal, something like 24.3.1-hotfix, so exposing it raw recreates the leakage you're trying to avoid. And the Release Date on a version is optional, so it's very often blank or stale. It's a fine pattern, it just depends on naming and release-date discipline you may not have yet.

Either way, the customer only sees a field if it's on the Fields to display to customers list for that request type. That's configured per request type, so it's easy to set one up and quietly miss the others.

For keeping it in sync, automation is bundled natively in DC from the Jira 9.x and JSM 5.x generation onwards, so no separate app if you're reasonably current. One suggestion on the trigger though. I'd avoid triggering on sprint started, because a sprint starting doesn't mean the item finishes in it, and you'd be making a promise the sprint can't keep. Trigger on Fix Version or your Target date changing on the dev issue instead, and copy that across the link.

Two details that make the automation reliable:

- Use a dedicated link type between the request and the dev issue rather than the generic relates to. Something like has development work. Generic relates to gets reused for everything and becomes unreliable to match on in JQL and in rules.

- Field updates don't notify customers. Only a comment shared with the customer, or a status change, does. So pair the field update with a customer-visible comment, and throttle it. Comment when the release or the date meaningfully moves, not on every replan, otherwise people learn to ignore them.

One thing worth confirming, your title says Data Center but the tags on the post say Cloud. Most of the above holds either way, but the boards answer and some of the automation specifics differ, so it's worth saying which you're actually on.

Alex