Product Owner is a role prescribed by the Scrum framework. It is called “Product” Owner because in a Scrum context, we usually manage a product that is generally a standalone software. The Product Owner’s responsibilities are to maintain a Product Backlog, to keep a channel of communication with the Stakeholders and to answer the team’s questions. His main goal is to maximize the value delivered by the team through the prioritization of the backlog.
The first principle of the Kanban method is to start with what you do now. Therefore, if you are new to Kanban, there is no need to introduce a new role called “Product Owner”. Moreover, the Kanban method is usually adopted in the context of delivering services. It is hard for a single person to maintain and prioritize a backlog when the people doing the work are bombarded by requests from many other groups inside or outside the organization.
Everyone wants what they asked for NOW! So how do you keep everyone happy? Instead of spending a lot of time and energy on prioritization, Kanban offers a simple alternative: Classes of service. Classes of service are used to classify specific types of requests into levels of urgency.
Classes of Service
The Kanban method proposes four archetypes of classes: Standard, Fixed Date, Intangible and Expedite. Every time you receive a new request, it should be classified into one of these classes of service. For each of these categories, the delay required to deliver the request will be different.
Most of your requests should be treated using the Standard class. Fixed Date requests have a specific delivery date and should be treated with greater urgency than standard items in order to respect the deadline. Intangible items are the lowest priority. Intangibles are usually pieces of work that do not affect the client directly, such as a software upgrade, or doing a manual backup. Expedite requests should be occasional only and they have precedence on all other classes of service.
But how do you prioritize multiple items from the same class of service? You don’t! You simply threat them first in, first out. It often takes more time to decide in which order to do the work than to just do it!
Service Levels
Keep in mind that you are not limited to these four classes of service, it is up to you to determine if they are right for you. You can define your own classes of service. Remember that each class will have its own level of urgency and the delay to deliver items will be different. This information will help you define the SLE (Service Level Expectation) for each class of service, from which you can then negotiate the SLA (Service Level Agreement) with your clients.
But what if we really need to prioritize items from the same class of service? Whose responsibility is it to do that? It really depends on your context. If you feel you still need to prioritize your work, someone could wear the hat of Service Request Manager.
The Service Request Manager
A Service Request Manager is responsible for understanding the clients’ needs and the expectations. Unlike a Product Owner in a Scrum team, it doesn’t have to be a formal role. It could simply be the most experienced person in the group or it could be held on a rotation basis. With the help of the group, the Service Request Manager will order work items from the backlog and facilitate selecting what comes next.
And what if my team is transforming the way we work from Scrum to Kanban? Should we abandon the role of Product Owner? Of course not! Keep your Product Owner if you are used to it. Remember the first principle of Kanban: start with what you do now. That means you do not have to introduce new roles, but also that you do not have to get rid of existing ones! And if you are in a context where you manage a product, maybe you need that Product Owner to maintain the communication channel open with the stakeholders.
So, do you need a Product Owner if you use the Kanban method? You do not have to introduce this role if you are not using it already. Besides, it is possible that the need of a Service Request Manager will emerge by itself overtime. But if you already have a Product Owner in the group, you can keep that role if it makes sense in your context, and it is also possible that it will disappear by itself over time.
If you want to learn more about the Kanban Method, Pyxis offers Kanban coaching as well as certification courses from the Lean Kanban University: Team Kanban Practitioner (TKP) and Kanban Management Professional (KMP II).
1 Comment
I enjoyed reading your article, I like the premise and cautiously believe that more Kanban practitioners are not quite clear with this context.
I like to begin with a problem statement, denotation vs. connotation of “Product Owner” is fuzzy to many. Differentiation between “role” and “position.” In some way I feel your article views PO as a person, position fulfillment.
The idea of Product Ownership by Cambridge styled application of the English language connotes – role, that is behavior expected within the SDLC. People or somebody are/is always needed to interface between consumers or users to understand their needs.
Now, whether a single person tilted PO does it or SM does it, or Development team interfaces for this purpose: it does not change the fact that the PO (a set of behaviors) is required. It simply connotes a shift in behavior expected from the team, as in the development team acts on behalf of a single person popularly referred to as a PO. The PO behavior (role) cannot be eliminated, in other words it’s a form of energy that drives priority – and energy is neither created nor destroyed.