Classic plans iteration-based scheduling (Scrum)
On an iteration-based scheduling, stories and their work stages are scheduled into defined iteration lengths. These can be either manually entered as fixed sprints, or you can allow Portfolio for JIRA to dynamically schedule them based on available resources, release dates and scope.
If you schedule work that contains different stages, the exact stages completion order is not relevant, only what fits in the overall sprint matters.
Story scheduling is dynamically forecasted depending on sprint length, available resources and release dates, unless you have configured fixed sprints for individual teams. Fixed sprints are set for a team with a beginning and end date and are used and give you an additional way to match how your team works in the real world with your plan. See Releases, teams and member assignments for more information.
The simplest way to schedule stories is to define just one stage of work such as "implementation" and assume that everyone can do everything.
Follow these steps to create a story with a single stage:
Additionally, you can define one release with a fixed end date, so that the algorithm automatically fills in as many stories into the release as possible.
Take a look at the backlog and add several stories with estimates, you can see in the schedule's story view that the stories are sequentially filled into sprints.
The sprints have a duration of two weeks as configured in the team's settings; the first sprint starts with the first release start date.
- Stories are filled by priority into as many sprints as required.
- The first sprint starts with the release start date.
Switching to the release and capacity view will reveal that Sprint 1 is completely booked. Story 4 and Story 5 slipped into Sprint 2, which fills up this sprint to 50%.
Add two more stories and prioritize them after story 2:
The stories are pushing story 3 to the next sprint.
Even though there is free capacity in sprint 1 of 4 days, none of the remaining stories can fit into this sprint.
This example shows the effect of scheduling for complete deliverables. While there are four days of capacity left, the goal of an iteration is to have a deliverable increment, so it does not make sense to finish "half" a user story. If you want to use the free capacity, break down any of the other stories into smaller units.
Stages are scheduled sequentially per story by default allowing you to plan for different types of work.
Follow these steps to create a story with a single stage:
Example: You want to plan for story writing and implementation:
In the backlog story view you see that the different work stages are scheduled sequentially:
- In the first sprint, implementation cannot be started yet, since there are no stories yet written.
- The product owner is scheduled to write stories 1, 2 and 3 in the first sprint based on his capacity
- The team can then implement these stories in sprint two, while the PO completes the next stores
At the beginning of the release there's a ramp-up time with the first design steps to be completed until the implementation of these items can start. In practice, this can avoided in multiple ways:
- Plan for some stories without design effort, such as technical preparation, prototyping or similar.
- Work with overlapping releases so that the design work of the next release can already start while the last stories of the current release are still being implemented. See Configuring releases for more information on this topic.
In the example, the stages are scheduled directly into sequential sprints for all stories. However, this does not necessarily have to be the case: If there is not sufficient capacity, the algorithm would still try to start the first stage as early as possible, but there might be a gap then until the next stages can be completed.
The screen below shows the same example, but with one story "Technical Exploration" that has only implementation effort defined. Since all the other stories cannot be started until their design is available, this story can already be done in sprint 1.
Stages and sprint constraint control the different stages of work that can be scheduled into the same sprint, or into sequential sprints.
You can disable this constraint by following these steps:
- Go to Plan > Configure > Scheduling options.
Select On or Off.
Even Though turning the constraint off leads to shorter cycle times, the plan is not necessarily realistic, since it is only guaranteed that the total capacity of a sprint is not exceeded. It's assumed though, that the work for all stages can really be done in parallel during the sprint.
Epics can act as grouping elements for stories or if they don't have child stories associated, they can be directly scheduled as work items. This makes the scheduling of epics different in these two cases:
Example: You have two epics, each having several child stories:
In this case, the epics work just to group their child stories. The epics by themselves start when their first story is scheduled to start, and end with the completion of the last story:
Epics without child stories are scheduled as if they would be broken down into stories later on and therefore, they are suited to be used as placeholders for larger pieces of work that are yet to be planned in detail. The way they are scheduled ensures that the ratio of work is realistic under the assumption that while really implementing the epic, it will potentially be done in smaller increments, with deliverable work packages.
Example: A simple epic with a large estimate:
When looking at the stories view, we can see how it is scheduled under the assumption that it is a placeholder for multiple stories:
In the first sprint, a bunch of story writing is done (green). This allows in the next sprint to schedule an amount implementation, relative to the design done in sprint one. In the current configuration, Design accounts for 25% of the total effort. This means, if we can fit in 10 days of design work into sprint 1, up to 30 days of implementation work could be scheduled for sprint 2 and so forth.
Minimum load configuration
Stories are always filled as a whole into a sprint. If the full story does not fit in, it gets pushed into the next sprint.
For epics, in order for the schedule to be realistic, in most cases it is desired to resemble this behavior. That's what the minimum load setting is designed for.
Example: Several stories are scheduled first and epic 2 is scheduled for the last two sprints.
Looking at the releases/capacities view reveals that there would have been free capacities in sprint 2. However, the configured minimum workload is 5 days, so the item is not scheduled in a smaller increment.
How to turn the minimum load constraint off
When turning this constraint off, we see that the epic is scheduled to fill up any free capacities also in earlier sprints.
This results in a higher resource utilization, but might not necessarily reflect reality. If there is half a day left in a sprint, would you really start partial work for an epic?
Still, depending on how you use epics, there are situations where it is helpful to turn off this constraint, and maximize capacity utilization.
All of the examples above show dynamic scheduling of work based on the information you have entered into your plan. Scrum teams can also have fixed sprints assigned to them (in the Sprint menu in the backlog) giving you more flexibility when scheduling. Fixed sprints allow you to set begin and end dates that a team will be working in a specific sprint which can be different from a team's typical cadence. See Working with Teams and Members for more information on setting up Fixed Sprints.