Issue Summary

Customers need a choice of allocation modes in Jira Plans. In addition to the current capacity-driven scheduling model, teams should be able to select a concurrent allocation mode that distributes long-running work across its target-date range to reflect multiple people working on tasks in parallel.

Today, Jira Plans schedules work based on individual team-member capacity and deadline-oriented scheduling behavior. For teams planning work that will realistically be performed in parallel by multiple people throughout a long date range, this can result in remaining allocation appearing concentrated in the final available period before the Target End date.

Steps to Reproduce

1. Create or open a Jira Plan with a team containing multiple members and a defined weekly capacity.
2. Create long-running work items with estimates, for example, 40h, 80h, or 200h.
3. Set Target Start and Target End dates that span several months, for example, July 1 through December 31.
4. Assign the work items to the plan team and configure dependencies or scheduling as applicable.
5. View the allocation/capacity timeline for the work items.
6. Observe how Jira Plans allocates the estimated work across the available timeline.

Expected Results

Provide an optional scheduling or allocation mode that distributes long-running work evenly or according to a configurable distribution method across the full Target Start to Target End date range.

For example, when a work item has a six-month target-date range and an estimate representing work expected to occur throughout that period, customers should be able to choose a planning mode that displays a consistent allocation across those six months.

Actual Results

Jira Plans allocates work according to the current scheduling model, which evaluates individual team members' capacity and schedules the remaining work to meet the Target End date.

For long-running work items, this can result in allocation appearing concentrated or stacked in the final available period of the target-date range, rather than being visibly distributed across the entire range.

Changing scheduling from sequential to concurrent did not produce the desired even distribution for the customer's scenario.

Workaround

Currently, there is no known “workaround” for this behavior. Customers can creatively redesign the math around capacity assignment with formulas such as the following example:

Example of Concurrent Distribution by Formula. 
• Issue estimate: 2,080h
• Plan duration: 52 weeks
• Team members: 2
• Configured team capacity: 40h/week
Plans calculates:
Individual weekly capacity = 40 ÷ 2 = 20h/week
Schedulable work = 20h/week × 52 weeks = 1,040h
Final-period stack = 2,080h − 1,040h = 1,040h
So, to make a 2,080-hour issue distributed across the whole 52-week range under the Plans’ current model:
Required team weekly capacity = (2,080 ÷ 52) × 2
= 40 × 2
= 80h/week