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.
Scheduling stories
The following examples are using a configuration with 3 stages of work: design, implementation, and test.
Epic scheduling
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:
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.