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 three certification courses from the Lean Kanban University: Team Kanban Practitioner (TKP), Kanban System Design (KMP I) and Kanban Management Professional (KMP II).

 

 

Previous post

More than just brains at work: A conversation about active listening in coaching (part 2).

Next post

Stories of Agility in IT Operations

Pierre Leblanc

Avec plus de 15 ans d'expérience en TI, Pierre a travaillé dans différents types d'entreprises : de la « startup » à la multinationale. Il est en mesure de s'adapter à toutes sortes d'environnements. Par ailleurs, il a été entrepreneur de 2003 à 2007; période durant laquelle il a développé ses habiletés de leadership, de développement des affaires et d’enseignement.

Il a commencé son aventure en gestion de projets Agiles en 2009 dans une équipe Scrum. En 2011, il est devenu Scrum Master pour une équipe distribuée. En 2014, Pierre a décidé de délaisser le côté technique pour se concentrer sur l'aspect humain des TI en devenant coach Agile.

Toujours en quête d'apprentissage, il est membre de l'organisme Toastmasters International, où il peut exercer ses talents d'orateur et continuer à développer ses qualités de leader en tant que responsable de district.

No Comment

Leave a reply

Your email address will not be published. Required fields are marked *