Understand Service & Purpose
This domain tests whether you can say what a Kanban system is for: which service it provides, to whom, and how purpose drives every later design choice.
A service, not a team
Kanban treats an organisation as a network of services. Each service takes a request from a customer and turns it into something that customer values. The customer may be external or the next team downstream - both count.
Purpose is the aim of the system
Purpose answers: what outcome do we produce, for whom, and how would they know it was good? State it as a measurable customer outcome, not an activity. Deming's point stands - a system must have an aim everyone can see.
Service delivery principles
- Understand and focus on your customers' needs and expectations.
- Manage the work, not the people; let people self-organise around it.
- Evolve policies to improve outcomes.
These sit alongside the change principles: start with what you do now, pursue change incrementally, encourage acts of leadership at all levels.
Worked example
A platform team writes: "We keep the servers running." Rewrite: "Product teams can provision a compliant environment themselves in under one working day." Reasoning: the first is an activity measured by uptime alone; the second names the customer, the outcome and a measurable lead time. From it the team can derive work item types (environment requests, incidents), the commitment point, service expectations, and a class of service for incidents. It also exposes demand the team previously ignored - self-service requests - which becomes a source of dissatisfaction to investigate.
Traps that cost marks
- Naming a technical specialism or a project as the purpose.
- Ignoring internal customers downstream of the team.
- Treating purpose as permanent instead of reviewing it at the strategy cadence.
- Writing a purpose the customer would not recognise.