Welcome to the Home of Scrum! ™

TL; DR: Product Owner Interview Questions — The Product Backlog and Refinement If you are looking to fill a position for a Product Owner in your organization, you may find the following 71 interview questions useful to identify the right candidate. They are derived from my fourteen years of practical experience with XP and Scrum, serving both as Product Owner and Scrum Master and interviewing dozens of Product Owner candidates on behalf of my clients. So far, this Product Owner interview guide has been downloaded more than 8,000 times. 🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 30,000-plus other subscribers. Join more than 145 peers from May 27-29, 2021, for the Virtual Agile Camp Berlin 2021, a live virtual Barcamp using open space technology principles and practices. 71 Product Owner Interview Questions Scrum is not a methodology but a framework. There are no rules that apply to each scenario, just good practices that have worked in other organizations before. Hence, you have to figure out on your own what is working for your organization. Finding this answer is a process and not a destination. The role of the Product Owner itself is making the hiring process difficult to handle. The Product Owner is the least well-defined accountability within the Scrum framework and—at the same time—the one Scrum role with the most facets. (Please note that I will continue using ‘role’ on occasions throughout this document, although the Scrum Guide 2020 now speaks of ‘accountabilities.’) A Product Owner is an innovator at heart and thus a value creator for customers and organizations if given a chance to work in an agile manner. The Product Owner is also the most vulnerable Scrum role. Turn them into a [fill-in a ticket-system of your choice] monkey or deprive them of the ability to say ‘no’—as in being the guardian of the Product Backlog—, and the Product Owner quickly becomes the Achilles heel of any agile organization. The Product Owner role depends on the size of an organization, the industry it is operating in, its culture, and the lifecycle stage of that organization’s product(s). Lastly, there is an overlap with the product manager role. (Spoiler alert: they aren’t identical.) The following interview questions are neither suited nor intended to turn an inexperienced interviewer into an agile software development expert. But in a seasoned practitioner’s hands, they support figuring out who of the candidates has been successfully working the agile trenches in the past. Remember, “Agile” is a mindset, not a methodology. Hence, no checklist can drive your recruiting success to the desired outcome. Download your free copy of the 71-question-strong interview guide here: Product Owner Interview Questions: The Organization of Questions and Answers The ebook provides both questions as well as guidance on the range of suitable answers. These should allow an interviewer to deep dive into candidates’ understanding of Scrum and their agile mindset. However, please note that: The answers reflect the personal experience of the author and may not be valid for every organization: what works for organization A is probably failing in organization B, There are not suitable multiple choice questions to identify a candidate’s agile mindset given the complexity of applying “agile” to any organization, The author has a holistic view of agile practices: agile equals product discovery (what to build) plus product delivery (how to build it). 19 Product Owner Interview Questions on the Product Backlog, Refinement, Forecasts, and Estimates Please find the following 19 of 71 Product Owner interview questions to identify suitable candidates for the role of Product Owner, addressing the Product Backlog, Product Backlog refinement, work items, forecasts, and estimates: What is the purpose behind the Product Backlog refinement? The refinement is a continuous process to create actionable Product Backlogs that allow a Scrum Team to have a Sprint Planning at a moment’s notice. The Scrum Team accomplishes this level of preparedness by regularly refining Product Backlog items in small groups or with the whole Scrum Team, and not just once every Sprint as part of the Sprint Planning. The idea behind the refinement is to create a shared understanding with all team members, why a particular work item is valuable, what the Developers shall create, and how to realize the work item technically. How much time should you spend on Product Backlog refinement? While the Scrum Guide 2020 drop the previous guidance on the time allocation, it remains a practical rule of thumb that the Scrum Team should reserve up to 10% of its time for the Product Backlog refinement. How would you organize the “refining” process of Product Backlog items? In general, it is beneficial to structure the refinement process around questions such as: What items are no longer relevant? What items need to be split? What items can be updated with new information? Does this update change previous estimations? Has the priority of specific items changed? Do we have any new topics or learnings that haven’t yet been considered? (If yes, these need to be captured as new Product Backlog items.) How many Product Backlog items can you work on in parallel to ensure continued relevance to customers and the company? It depends on several issues, such as the balance between stakeholder communication, customer research, and the Product Owner’s commitment to their Scrum Team. Working on more Product Backlog items than the team can handle in two to three Sprints at the same time might prove to be difficult, though. Often, if Product Owners cannot allocate sufficient time to a single item, they waste resources on half-baked work items of a questionable value. You love using the Product Backlog as a kind of repository, adding ideas to continue working on them at a later stage. Over time, you have created over 500 tickets in various stages. What is your take: Can a Scrum Teamwork effectively on 500 tickets? From my experience, any Product Backlog that is larger than the scope of three or four Sprints is barely manageable if you want to maintain an actionable Product Backlog. Misusing a Product Backlog by adding hundreds of items to it is a clear sign that the Product Owner needs help from the Developers and the Scrum Master to better cope with the influx of ideas, suggestions, and requirements to avoid misallocating resources. Lastly, beware of appeasing nagging stakeholders by merely adding their “requirements” to the Product Backlog. This does not solve the issues; it just postpones the inevitable discussion as the stakeholders will now expect that the Scrum Team will create their Increment. At what level do you include other team members in the refinement process? When the foundation of a Product Backlog item is ready for that. The readiness isn’t easy to generalize since it depends on the nature of the product itself, the Scrum Team’s experience, and the organization’s leadership style. From my experience, this influences the readiness and availability of a Scrum Team to contribute to the refinement process effectively. For creating a shared understanding of the why, what, and how of a work item among all team members, the precise moment of involvement is crucial. If the team is involved too early, the Developers may consider this a waste of their time. If the Scrum Team is involved too late—for example, all specifications have already been prepared—, they may feel not respected. If in doubt, the Product Owner should include the Scrum Master in the process. How do you identify the value of a Product Backlog item? Some proven categories to define value are projected revenue increase, cost cutting effects, a projected growth of the customer base, and an increase in customer satisfaction rates. More metrics are available from Scrum.org’s Evidence-Based Management model. How do you communicate to your team members the value of a backlog item? Product Owners communicate value with any information suitable to further the Scrum Team’s understanding. That communication can be quantitative, such as analytical data describing how a process is utilized, financial projections, an increase in conversion rates, acquiring new customers, etc.) It can also be qualitative, such as transcripts, screencasts, or videos from a user testing session. Preferably, the Scrum Team members already know in advance as they are regularly participating in user research activities. What are good practices to order Product Backlog items? Criteria to determine the order of a Product Backlog item, for example, are value, risk, work estimates, available expertise, and dependencies. How do you handle bugs and technical debt when many valuable new features are competing for resources? Focusing solely on shipping new features is a slippery slope that quickly leads to the build-up of technical debt. You trade a short-term win—shipping more features—for a long-term liability. Technical debt will inevitably slow down the creature of new Product Increments in the future, probably to a point where the product seems to be at a standstill. In other words: By accruing technical debt, the very purpose of becoming agile—learning faster as an organization than the competition, thus being able to exploit market opportunities—is at stake. Hence it is a good practice to allocate around 20 percent of the Scrum Team’s capacity to keeping technical debt at bay at any given time. Experienced Product Owners support this long-term thinking. Why is user story mapping a useful technique for Product Owners? User story mapping a great way to visualize the “big picture” within a Product Backlog. Additionally, user story mapping is an instrumental means to improve communication with stakeholders and the Scrum Team. These workshops create a shared product understanding across teams, roles, and departments. How do you best create Product Backlog items? The best way to create Product Backlog items, particularly user stories, is a collaborative and iterative approach, using collective inspection and adaptation, including the whole Scrum Team. User story creation should not blindly follow a specific template but rather be a lively negotiation with the team, focusing on reaching a shared understanding of “why,” “what,” and “how” with all team members. What shall a good user story look like? What is it structure? For software development, the attributes of an exemplary user story are: The description is available, Acceptance criteria are defined, The story can be delivered within a Sprint, All UI deliverables are available, All (probable) dependencies are identified, Performance criteria are defined, Tracking criteria are defined and The story is estimated by the team. (I do believe that you cannot “not estimate” one way or another. Even the #noestimate approach includes a sizing model that is based on a kind of unspoken estimation.) Product Owners should be familiar with Ron Jeffries Three-Cs—Card, Conversation, Confirmation—and Bill Wake’s INVEST principle. Where are you discussing user stories, only during refinement sessions? The best way to discuss a user story is by doing so synchronously with all involved team members to ensure that a shared understanding is created. This approach works for co-located as well as distributed Scrum Teams. Asynchronous discussions may be an option when team members cannot participate in a discussion or when the Product Owner is in the field, and feedback is required. It would help if you avoided, though, lengthy discussions via comments on tickets. That’s a sign of a weak refinement process as it creates unnecessary queues of idleness. What are typical pitfalls of the Product Backlog refinement? Some of the typical pitfalls of a backlog refinement are: There are not enough refinement sessions, resulting in a low quality of the Product Backlog. There are too many refinement sessions, resulting in an overly detailed Product Backlog, resembling an upfront planning from the old waterfall planning ages. Turning requirement documents from stakeholders into user stories without involving the Scrum Team. Not involving the whole team in the refinement process, probably just the “lead engineer”. Not involving stakeholders. This open question is an invitation to Product Owner candidates to share from their previous experience and how it influenced their current understanding of proper Product Backlog management. There is an extensive list of anti-patterns available in the following article: 28 Product Backlog and Refinement Anti-Patterns. Is it necessary to include detailed acceptance criteria with a user-story? Generally, acceptance criteria define the functional and non-functional requirements that need to be met. The level of detail may vary depending on the nature of the task. Hence, it is a good practice to include the Scrum Team in their creation as some of those requirements may already be addressed by the team’s Definition of Done. The Scrum Team requires time to investigate a technical issue with a user story to understand its requirements better. How do you continue with the refinement process of the particular user story? Borrow from XP and run a spike during the next Sprint. Once the team can provide better insights to its technical side, come back to the user story, and resume the refinement. One of your stakeholders presents you with such elaborate requirement documents that you copy them into Product Backlog items. Nevertheless, your Scrum Team is not pleased with this approach. Why is that? Product Backlog items are a token for discussion to create a shared understanding and secure the Developers’ buy-in. If the Developers are not involved in devising, disseminating, and capturing these, they do not see any ownership in such work items. This likely results in a lower level of engagement, which may negatively affect the value created for customers. When would you remove a feature? The best way to “remove” useless features is not to build them in the first place. Simplicity and radical focus on value delivered to customers is key to any successful agile product organization. Should—despite all validation efforts during product discovery—a feature of lesser value slip into the Product Backlog and be delivered, it should be removed as soon as possible from the live product. The same applies to an existing feature that has outlived its usefulness. The Conclusion: Product Owner Interview Questions — The Product Backlog and Refinement Scrum has always been a pragmatic business, and to succeed in this mindset, candidates need to have a passion for getting their hands dirty. While the basic rules are trivial, getting a group of individuals with different backgrounds, levels of engagement, and personal agendas, to continuously deliver value by creating a great product is challenging. The larger the organization is, the more management level there are, the more likely failure in one of its many forms is lurking around the corner. The Product Owner interview questions are not necessarily suited to turn an inexperienced interviewer into an agile expert. However, they support figuring out what candidate has been working in the agile trenches and who’s more likely to be an imposter. (You should avoid inviting candidates from the latter category to a trial.) Hence it’s probably a good idea to look for a pragmatic veteran who has experienced failure—and success—in other projects before and the scars to prove it. ✋ Do Not Miss Out and Learn about Product Backlog and Refinement: Join the 9,000-plus Strong ‘Hands-on Agile’ Slack Team I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world. If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free. 71 Product Owner Interview Questions — Related Articles Hiring: 71 Scrum Product Owner Interview Questions to Avoid Agile Imposters 28 Product Backlog and Refinement Anti-Patterns Product Backlog Defense – Common Patterns of Stakeholder Interference A Forensic Product Backlog Analysis — Making Your Scrum Work Product Backlog Anti-Patterns Q&A Product Discovery Anti-Patterns Leading to Failure

En enero de 2020, tuve una entrevista telefónica para un proyecto de transformación ágil con un líder de una empresa con sede en Barcelona que estaba interesado en agile coaching. El entrevistador me preguntó si me gustaría lanzarme a una conversación de coaching y acepté. Durante los siguientes minutos, hice todo lo posible por ponerme un sombrero de coach profesional, aunque, al final, mi intento no demostró las capacidades que buscaba el líder de la transformación. ¿Qué salió mal? Paralelamente a la entrevista telefónica, estaba iniciando mi programa de coaching en ICF, un programa intensivo de 9 meses. Parte del plan de estudios implicaba demostrar la capacidad de coaching y requería sesiones grabadas para trabajar con los clientes a través del arco de coaching. La organización con la que estaba intentando llevar una transformación ágil en ese momento no tenía experiencia en conversaciones de coaching profesional. De nuevo, choqué contra una pared de ladrillos. Sentí frustración y comencé a tomar el tema como algo personal. Conozco bastante bien las prácticas ágiles; ¿Por qué el coaching era tan problemático para consolidarlo en una organización? ¿Cómo lo veo desde mi experiencia? En mi experiencia laboral personal, desde start-ups hasta grandes empresas, pocas veces he presenciado una conversación de agile coaching en acción, pocas veces también he visto su uso como una prioridad para el cambio organizacional. El líder, a quien entrevisté, era un raro tesoro enterrado en la arena. Cuando le hablé de la capacidad de coaching, me refiria a lo que la International Coach Federation (ICF) define como colaborar con los clientes en un proceso creativo que invita a la reflexión y que les inspira a maximizar su potencial personal y profesional. Como parte del compromiso con el cliente, me refiero estrictamente al uso del arco de coaching. Os adjuntamos una imagen de ese arco tal y como lo entendemos. Dado que he trabajado junto a varias personas que se autodenomian Agile Coaches, la mayoría de las veces no he presenciado el arco en acción. Siento que la expectativa de la industria del Agile Coaching en el papel es diferente a la realidad. El arco de una sesión de coaching profesional Por otro lado, con frecuencia presencio y me encuentro muchas veces con las otras tres posturas del Agile Coaching Competency Framework. Esas competencias son teaching, mentoring y facilitation. El coaching no está presente en la mayoría de ocasiones. Por desgracia, a eso le terminan llamando Agile Coaching. También he presenciado muchas veces que las organizaciones asignan a un coach que impone objetivos definidos por la propia organización a su coachee en cuestión. Esto pasa por encima de los códigos de ética que tienen los coaches profesionales en desarrollo de su trabajo. Aunque la competencia de coaching sea un cuadrante más del framework, no significa de que no tenga un código de ética. La mentoría acostumbra a ser la intepretación de muchas organización sobre lo que hace un Agile Coach. Independientemente de la madurez ágil, si tienen, las organizaciones parecen gravitar y aceptar los otros tres atributos teaching, mentoring y facilitation mucho más que la competencia de coaching. ¿Por qué es esto? Algunas observaciones en agile coaching Nuevamente, a través de mi observación, creo que las organizaciones en los rangos de madurez ágil medio y bajo no están preparadas para conversaciones de coaching honestas. Cuando los ejecutivos emplean a un Enterprise Agile Coach, este acto generalmente indica un reconocimiento de que debe ocurrir un cambio interno dentro del sistema. Y una auténtica conversación de coaching sacará a la luz brechas que algunos líderes quieren que se dejen enterradas. La exposición puede revelar vulnerabilidades y pérdida de poder para ese líder, especialmente en un entorno del tipo de comando y control. El cambio real da miedo a algunas personas. He sido testigo de primera mano de lo lejos que llegan algunos líderes para mantener los negocios que tienen entre manos y proteger su reino cultivando la ilusión del falso control. La mayoría de las ofertas de trabajo para los coaches ágiles se centran en el conocimiento del dominio de la agilidad más que en la postura del coaching. Si las conversaciones de coaching son un requisito, la próxima vez que veas un puesto de Agile Coach abierto, observa qué tipo de lenguaje utiliza la organización para describir las competencias básicas. Las empresas intentan maquillar lo que no son, sin embargo, las descripciones de esos puestos revelan su nivel de madurez para un Agile Coach. Es más, muchas organizaciones intentan vender una imagen de que son ágiles porqué les da una diferenciación en el mercado para captar talento y negocios. Muchas veces ni se preocupan por definir las ventajas que realmente le daria consolidar una buena práctica de agilidad de negocio. Si tu organización tiene un presupuesto de formación, observa lo que sucede si solicitas la aprobación para tomar un programa de coaching profesional, como puede ser CoActive o de la International Coaching Federation. La forma en que responde el empleador indica la madurez ágil de la organización y la comprensión del papel de un agile coach. Conclusiones Con el tiempo, he notado una tendencia en la que la mayoría de organizaciones contratan un agile coach pero quieren un experto en el dominio de la agilidad en un área específica como Agile Transformation, Scrum, Kanban, XP o incluso SAFe. Una vía es elevar a un Scrum Master Senior que tiene un conocimiento profundo en un área en particular como es Scrum a un rol de Agile Coach. Terminan viendo que el Agile Coach es el jefe de los Scrum Masters y no debería ser así. Peor aún cuando a alguien le dan el título de Enterprise Agile Coach y lo ven como el jefe de los Agile Coaches que encima es el jefe de los Scrum Master seniors. Cómo ves, no se preocupan de los beneficios que puede traer una buena implementación de la agilidad, usando el Agile Coaching Competency Framework para lo que realmente sirve, que es para conocer las habilidades de un líder del cambio y cómo las puede transformar en competencias consolidadas en la cultura de la organización.

Una de las bases clave para ayudar a que tu organización se vuelva ágil es el uso del empirismo. Agile es cambio constante y nos tenemos que adaptar. El empirismo es el enfoque científico basado en evidencia, donde cualquier idea debe ser probada contra observaciones, en lugar de intuición. El empirismo se basa en tres pilares: transparencia, fiscalización y adaptación. La adaptación tiene muchos sinónimos, de los cuales «cambio» es el más común. Una de las razones por las que me gusta trabajar dentro del marco de Scrum es que existen claras oportunidades de aprendizaje integradas; de lo contrario, debe incluirlas la misma organización. Después de un breve período de tiempo, la organización y los equipos deben reflexionar sobre lo que ha sucedido y cómo afectan el desempeño dentro del ecosistema. Sobre la base de la mejor comprensión, el equipo debe decidir qué harán para mejorar las cosas buenas y eliminar las malas, es decir, deben concentrarse en cambiar el entorno en la organización para que sea mejor. Esto significa que las cosas serán diferentes. Si la situación no es diferente, entonces no hemos actuado sobre el aprendizaje (o tu equipo es perfecto). En la película El día de la marmota, el meteorólogo (Phil) se da cuenta de que está viviendo siempre en el mismo día. Luego se vuelve loco y rompe todas las reglas, y luego se aburre y luego se enfoca en mejorar. Luego, hace que cada día sea un poco mejor que el día anterior, hasta que obtiene el día perfecto. La resistencia al cambio que sufre al comienzo de la película es similar a cómo los equipos luchan por lograr el cambio. He visto a varios equipos quedarse atascados porque: Intentan cambiar demasiado No ven nada que cambiar El equipo está cambiando a un ritmo más rápido de lo que la organización puede aceptar. Intentar cambiar demasiado Limitamos la cantidad de cosas que va a cambiar. Si es algo importante o desafiante, solo realizamos una acción. Hablamos sobre este elemento en cada Scrum diario. Nada que cambiar Hay dos extremos para esta mentalidad, un extremo es estar abrumado y el otro extremo es el de no ver ninguna forma en que el equipo pueda funcionar mejor. En ambas situaciones, una forma de evitar esto es enfocarse en una visión clara. Si el equipo tiene un objetivo / próposito común, entonces el estado actual se puede comparar con ese objetivo y luego encontrar el cambio que dará el mayor beneficio con el menor esfuerzo. Una vez que se promulga un cambio, no importa cuán pequeño sea, entonces debemos remar en la misma dirección para que el impulso puedeacrecer. Cambio de visión de equipo vs a visión de organización A menudo, los equipos más pequeños obtienen la idea de que la agilidad es un proceso continuo y una mentalidad, no un estado. Muchas organizaciones y líderes piensan que lo ágil es una solución milagrosa, que se invoca y eso es todo lo que se requiere. La organización debe adoptar la mentalidad de que las cosas serán diferentes, todos los días, todas las semanas, todos los meses, siempre. Eso está en el corazón de la agilidad empresarial. Ayudar a que esta comprensión se afiance a un nivel más amplio es responsabilidad de todas las personas que ayudan a desarrollar la agilidad de la organización. Es tu responsabilidad, como líder del cambio. Dependiendo de la organización, el uso de un marco puede ayudar. La estructura de un marco proporciona la solidez necesaria para incorporar un cambio duradero. Pero tiene que gozar de buena salud y de acompañamiento constante. Verás que tu equipo está activamente siendo ágil cuando use la frase «para nuestro equipo, hemos encontrado …» para describir sus formas de trabajar, independientemente del marco con el que comenzó. Además el equipo se habrá desarrollado en un estado de mejora continua, utilizando herramientas y técnicas ágiles para entregar un mejor producto, con mayor frecuencia. Y recuerda, Agile es cambio constante.

On today’s episode of YOUR DAILY SCRUM: What does a Scrum Master care about? Today's question asks what a Scrum Master truly cares about when working with a Scrum Team and the wider organization.