The product owner converts stakeholder requirement documents into tickets and asks the team to estimate them. Are you ok with that?
Welcome to part 23 in our scrum master interview questions series where John McFadyen answers common questions asked of scrum masters in interviews and client engagements.
Very often, especially in interviews, we come across questions that use terminology or jargon, but it isn’t clear that we all agree on what those mean.
So, I would start by clarifying what we mean by stakeholder requirements, and I would ask for clarity around what is meant by a ticket, from the perspective of the person interviewing you.
It may seem commonplace or common, but it is worth interrogating the term and understanding more about what they mean by those terms, and what answer would best serve their question.
I know from previous experience that in many systems, people refer to a ticket as a problem or issue raised by a customer or end-user.
I did do a tour of duty on the service desk, in my early days as a programmer, and in the context of that job and organization, a ticket referred to a specific problem or complaint related to the software or hardware environment we served.
So, if that is what they are referring to, it isn’t a bad thing at all. It’s just a generic term used to reference a problem that a customer is experiencing with either the hardware or the software.
In scrum, and many agile frameworks, a backlog item is a generic term we use to refer to a specific customer need, problem, requirement, or desire. It wouldn’t be referred to as a ticket because it references so much more than a straightforward problem or malfunction.
Stakeholder requirement documents.
This could mean absolutely anything.
It could be a 1,000-page report that details everything that the customer or end-user requires from a product, or it could be a one-page summary of functionality that a customer would value.
In the context of an interview question, it would be a dog show if thousands of pages of documents were being fed to the scrum team to analyse, evaluate, and estimate. If it was a quick estimate of 3 items that are incredibly urgent and valuable to a customer, that wouldn’t be a problem at all.
Also, is this the norm? Does the product stakeholder do this on a regular basis or is this a once-off request to address an impending crisis?
Context is key to understanding whether this kind of behaviour is problematic in an agile environment or whether it is a great opportunity for the team to pull together and do the product stakeholder and customer a solid favour that promotes trust and respect.
What do we want to see in an agile environment?
We want to see great communication between developers, product owners, customers, and product stakeholders. We want that to be a two-way communication stream that is respectful, valuable, and actively helps the team solve the most compelling problems and build the most valuable products.
We want to see the product owner working closely with product stakeholders and customers to ensure that we are building the most valuable product or feature, and that we are solving the most compelling problems for both the customer and the organization.
Sometimes, that occurs in a few events and at other times it is ad-hoc.
A sprint review is an event where the developers introduce the new product or feature, have discussions around what was attempted, what was achieved, and why there might be a gap between those two things. Insight into what problem arose or what impediments prevented progress.
The product stakeholders and customers engage with the new product or feature and provide feedback on whether it solves their problem or enables them to do what is valuable to them.
It is an incredibly valuable event because it brings the agile team and the customers/stakeholders into a room to talk about the most valuable work being done, what the team will attempt next, and what needs to go back to the drawing board to meet stakeholder and customer requirements.
At the start of the product discovery process, everyone will meet to discuss a vision for the product and identify what the product should be, do, and provide.
In most cases, this happens between the product owner and the customers and stakeholders, but ideally you want the whole scrum team present for this. You want the people who have the problem discussing that problem, and their requirements, with the very people who can solve that problem or building that solution.
Some of these elements are incredibly hard to understand, and some have slight nuances that are incredibly important, and so this does need to be documented. We do want to capture these requirements into backlog items, user stories, and any additional format that will help the team.
In scrum, this would form the basis of a product backlog and the product owner would be working closely and continuously with customers and product stakeholders to prioritize items and size them correctly.
Sometimes, the product owner will capture a large chunk of work or a big, difficult problem that needs to be addressed. At the time, it was good enough to capture as it is, but when the team come together to discuss the item, they discover that they need more information or need to break the item down into smaller chunks of work.
In this scenario, the team may well want to have a conversation with the product stakeholder or customer most relevant to the item, and you would want to facilitate that conversation quickly so that the team can understand what is needed and decide how best to address it.
Having a great, working relationship with customers and product stakeholders allows us to do that.
We want to have the kind of relationship where customers and stakeholders are open to meetings that ensure the team is building the most valuable product or solving the most pressing problems.
One of the core agile principles, as articulated in the Agile Manifesto, is to welcome changing needs and requirements, even late in development.
We are committed to building the most valuable product and we want to ensure that we are always invested in delivering that, so if something comes up, we want the product stakeholder to be able to address that with the team and help the team pivot onto the most valuable work.
We want the product owner, and the developers, to be available for a conversation with customers and stakeholders when a crisis occurs, or new developments require us to pivot.
We also may have a scenario where the developers require additional information or want to explore alternative opportunities with the customer or stakeholder because what has been requested simply can’t be delivered.
Maybe the problem is unsolvable, and we need to identify the next steps or alternative opportunities that will deliver value to customers.
We want product stakeholders and customers to be available for those conversations, and we want the scrum team to be able to have open, honest, and respectful conversations with customers.
What we don’t want to see in an agile environment.
We don’t want to see a product stakeholder or customer sitting at their desk, drafting a document, and emailing it to a product owner for sizing.
We don’t want a senior product stakeholder bullying the team into sizing and prioritizing their work, at the expense of a customer and the team, simply because they have power and influence within the organization.
We don’t want to see the developers constantly interrupted from performing their work because they are being asked to size this, estimate that, and provide deadlines for queries.
Sure, if it is a once-off, compelling event then we certainly should draw the team together to help the product stakeholder out of a jam, but we don’t want this to be the norm.
Scrum is a lightweight framework that allows a team to build the most valuable products and features for customers. It is lightweight so that it provides flexibility in the system and allows us to follow guidelines without those rules being carved in stone.
We want to be responsive, and we want to be able to adapt quickly and effectively.
That said, the events and artefacts in scrum have been developed with specific reasons in mind and so we want to follow ‘best practice’ (for lack of a better word) to ensure that we are leveraging the framework effectively.
We don’t want to encourage waterfall-style project management practices, nor do we want to see the traditional power players treating a product development team like a personal assistant.
A scrum master plays a significant role in finding that balance and helping the team move forward.
About John McFadyen
For more information on John McFadyen, connect with John on LinkedIn at https://www.linkedin.com/in/johnmcfadyen/.
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.
#agile #agilecoach #agilecoaching #agileprojectmanagement #agileproductdevelopment #agility #businessagility #scrum #scrummaster #scrumtraining #scrumcertification #scrumalliance #agilecentre #johnmcfadyen #coach #coaching #certifiedscrummaster