A product owner assigns specific user stories to specific team members. How do you react?
Welcome to part 8 in our scrum master interview question series where John McFadyen answers common questions asked of scrum masters in interviews and client engagements.
That could go one of two ways, depending on how my day is going.
Don’t take it too seriously.
Option is to laugh at the situation and point out to the product owner that assigning work to specific members of the team isn’t their job. That is what a project manager does but has no place in a scrum environment.
I would remind them why we embrace agile in the first place, remind them of the value behind the scrum or agile framework adopted, and give them a gentle reminder that we excel as a team when people embrace and honour their own roles and responsibilities rather than interfere with others.
Assist the product owner
I would set up a meeting with the product owner and address the issue with them directly.
I would remind them of the product owner role and its responsibilities.
- The product owner needs to talk about why the backlog item exists, what specific problem needs solving or what specific value needs to be created, and so forth, but it is not their role to tell the team how to solve the problem or who should be assigned the work.
- The development team are the experts in product development, and it is their responsibility to figure out what needs doing, how best to do it, and assign the work to a developer.
Example of expertise in practice.
If a product owner needed surgery to solve a specific problem, they wouldn’t be telling the surgeon what to do nor would they be telling the surgery team who needs to do what and when.
They would rely on the expertise of the surgery team to make a call on how best to perform the surgery and they would rely on the professionalism and teamwork of the surgeons to decide who is best placed to perform specific elements of the surgery, and how it should be done.
Software engineering is the same.
There is no value in a product owner deciding how to solve complex, engineering problems when they don’t have the expertise to do so.
There is no value in a product owner assigning work to a specific person because they don’t understand the team dynamic, nor do they understand who has the necessary skills, expertise, and experience to best solve the problem or create the solution.
They are, however, in a great position to explain to the team why something matters, how that will serve the customer, and what a great definition of a job well done is.
Opinion versus Expertise
A product owner is entitled to an opinion.
How valid that opinion is, in the context of what needs to be achieved, is a completely different conversation, but the product owner is still entitled to their opinion.
They are also entitled to voice that opinion.
It may or may not hold valuable insights for the team, but it isn’t on us, as the scrum master, to prevent the product owner from voicing what matters to them. It is our job to create an environment of psychological safety, and that includes empowering people to voice their own perspective, thoughts, and ideas in an environment that values such a contribution.
So, let the product owner voice their opinion, just make it clear that the team will consider that opinion as one of several options, and are not obligated to action that opinion.
The development team are not thinking exclusively about efficiency, they are deeply invested in the effectiveness of the team.
John may be the best developer on the team, and that is why the product owner assigned the work to John, but the team may be invested in developing skills and cross-functional capabilities and decide to assign the work to a junior developer for that reason.
John may also be going on leave in a few days, and so he won’t be available to do the work, and as such, the team won’t consider assigning the work to him.
The team may want to experiment with pairing. They may decide that this item is the perfect opportunity for a junior developer to work with an experienced developer to grow skills and capabilities under the supervision of a master developer.
There could be a million reasons why someone, other than John – who was assigned the work by the product owner – is better suited to performing the work.
We need to make the product owner aware of these considerations and help them understand why agile, or scrum, embraces the idea of pushing decision-making down to the experts who have the skills, knowledge, and experience to best serve the desired outcome.
About John McFadyen
If you are interested in becoming an agile coach and value mentored, coach-driven skills development in your journey to mastery, visit our Growing Agile Coaches page.
If you like the idea of becoming a scrum master and want to achieve internationally recognised and certified accreditation as a scrum master, visit our Certified Scrum Master (CSM) course page.
If you are already a scrum master and want to upskill to a more advanced level of knowledge and agile coaching capability, visit our Advanced Certified Scrum Master (A-CSM) course page.
If you have several years’ experience as a scrum master and want to validate and certify your professional skills, visit our Certified Scrum Professional Scrum Master (CSP-SM) course page.
For more information on John McFadyen, visit https://www.johnmcfadyen.com or connect with John on LinkedIn at https://www.linkedin.com/in/johnmcfadyen/.
#agile #agilecoach #agilecoaching #agileprojectmanagement #agileproductdevelopment #agility #businessagility #scrum #scrummaster #scrumtraining #scrumcertification #scrumalliance #agilecentre #johnmcfadyen #coach #coaching #certifiedscrummaster