Classic plans continuous scheduling (Kanban)
Continuous scheduling is designed for teams who don't plan in time-boxed iterations such as the day-to-day scheduling that matches teams working with Kanban, but also more traditional planning and development processes.
The scheduler follows these principles in Kanban mode:
- Schedules stages sequentially: A stage can start directly after the previous one has been completed. Example: Once the design is completed, the implementation can start on the next day.
- Finishes a complete story rather than starting a new one ("one-piece-flow"): With a focus on completing deliverable work increments, the scheduling algorithm will first plan capacities to finish one story, before starting a new one.
The following examples are using a configuration with 3 stages of work: design, implementation, and test.
In this scenario, the team capabilities are evenly distributed. In order to enable Kanban scheduling, switch the team's schedule to Kanban mode.
Since the scheduling setting is configured per team, it is possible to have different teams working on different schedules within one plan.
When adding a few stories, we'll see that these are scheduled to achieve a one-piece-flow.
Example: The algorithm attempts to finish a complete story as fast as possible before dedicating resources to the next story.
The weekend gap is not visible in cases where the work for a stage starts before the weekend, but still continues afterwards. In that case a continuous bar is drawn avoiding clutter and many interruptions, particularly for longer activities spanning multiple weeks.
In the following scenario you have 4 team members who can all do every type of work from design to testing; all members are assigned to story 1 in parallel in order to finish it as fast as possible.
You can change the maximum number of resources that can work simultaneously on a story by following these steps:
- Go to Plan > Scheduling.
- Change the maximum resources field.
If you turn it to 1 only one member at a time can work on a story, so Bryan is assigned to story 1, the maximum limit is reached, but there are still free capacities so story 2 and story 3 are started in parallel.
Since there are only 3 stories, Jason is not assigned with any work and thus the whole release takes longer to complete (Sept 29th vs. Sept 23rdf in the previous configuration).
The following team has different skills/specializations.
Example: Bryan is the only one who does design, Jonathan and Linda do implementation, Jason is a tester. Linda can take over testing tasks as well as implementation.
This is what happens in the schedule:
- Before any implementation or QA can start, the design for at least one story needs to be completed, so first, Bryan has to start design work for story 1.
- After story 1 is designed, Jonathan and Linda can work in the Implementation. In parallel, Bryan can already start the design work for story 2
- After Jonathan and Linda have completed implementation, Jason starts with testing. Since Linda can do testing as well, and the priority is on completing story 1 as fast as possible, she's assigned to take over parts of the testing effort.
And the same schedule, rendered per team member:
Epics can act either as grouping elements for stories, or if they don't have child stories associated, be directly scheduled as work items. Thus, the scheduling of epics is rather different in these two cases.
Epics with child stories
The following example has three epics, each having several child stories. The child stories are scheduled according to the concepts explained above:
In this case, the epics just have a grouping functionally, but the schedule fully depends on the 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
Epics without child stories are scheduled as if they would be broken down into stories later on. Thus, they are perfectly well suited as placeholders for larger pieces of work that is yet to be planned in detail. The way they are scheduled makes sure that the ratio of work (e.g. between design, implementation and test) is always realistic, and 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. The way it is scheduled largely depends on the 'minimum workload' setting. Let's say it is configured to 1. This means, already after a minimum piece of design work is completed, implementation can be started.
Tip: This approach of scheduling ensures, that always a realistic ratio of work is being planned: Let's say design is 25% of the total effort, implementation is 50%. If a designer completed 5 days of work, then subsequently, 10 days of implementation can be scheduled. Even though there would be a capacity for 100 days, it is not realistic to do 100 days of implementation work, since there will not be enough designs ready beforehand.
With a higher minimum work package size, there will be a larger chunk of design work started, before doing implementation work.
- Minimum load is set higher
- Epic 1 (The Avengers) A larger design block is finished first, before implementation starts
- Epic 2 (The Beatles) QA is scheduled regularly as soon as a sizable package is through design and implementation
Looking at the schedule per team member, we see that Bryan is constantly working on the design, Jonathan is only doing implementation, but since Linda can do both implementation and test, she is scheduled to "switch" regularly, so that assumed, intermediate deliverables, can be completed, as if the epic consisted of smaller stories.