2. • Classes of Service divide tasks in different aspects
• Simplify prioritization
• Create parallel flows in one board
• Classes of Service in Kanban = multi dimensional
flows
• Different cycle times per class
Introduction
3. • Established Classes of Service
• Bug
• Standard Class
• Chore
• Fixed Delivery Date (Timeline)
• In general, there is no break of the flow necessary
Introduction
5. "Virtual" 3 Swim lanes
• Standard-Development
• Support / Evaluation
• Extremely important Tasks
One example of our
current practice
Backlog Ready Approval internal
Codin
g
Code review Testing
Deploy
staging
Feedbac
k
Approval customer Merge master Deploy queue
Productio
n
Done
Backlog Ready Approval internal
Codin
g
Approval customer
Approval
support
Done
Backlog
Approval
customer
Codin
g
Deploy queue Done
6. • Important class: urgent bug/ extremely important
• Take precedence over other classes
• Average cycle time from max one day
• For example: server down or an automation
change massive data in a wrong way
One example of our
current practice
7. • Evaluations are processed as "Research"
• Will be used to find a solution for a problem
together with our customer
• Can produce many Standard Feature tasks
One example of our
current practice
8. • Usefull but intangible tasks have the class Chore
• Chore - not urgent tasks
• Upgrades or support
• Little User Interface improvements etc
• Will be pulled by void or need for clarification
• Can escalate to urgent tasks if not considered for a longer
period (for example performance optimization)
One example of our
current practice
9. How take care of long living
Chore tasks?
• Bad solution:
• Own Chore queue
• Tasks should go into icebox
• But icebox tasks will often get forgotten
• Better solution:
• Prioritize the Chores with the customer into the backlog
10. Conclusion
• What we also need to take care on Classes of
Service:
• Tools to measure the cycle time per Classes
of Service
• Difficulty to do so in Kanbanery through
missing swim lanes