La pila de producto es la base en Scrum, si no hay pila, por supuesto que no tenemos nada que construir. Pero, ¿Qué es la pila de producto?. Básicamente es una lista priorizada de funcionalidades a desarrollar para un producto. ¿Todo el producto?, ¡No!. Con Scrum no necesitamos TODO lo que debe de hacer el sistema, sabemos de antemano que eso es difícil de saber e igual difícil de mantener estable, solo necesitamos lo necesario para empezar a trabajar, para empezar a dar forma a nuestro producto. Como mencionamos en la pila de producto incluimos funcionalidades, que en la mayoría de las veces, se hace con historias de usuario. También vamos incluyendo en esta pila a medida que vamos avanzando: Defectos encontrados, nuevas funcionalidades, Investigación, y trabajo técnico. ¿Por qué añadir otras cosas que no son funcionalidades?, es trabajo que el equipo tiene que realizar dentro de un Sprint. Por ejemplo, configurar o alistar los servidores, investigar al tipo de controlador que vamos a utilizar en el desarrollo, corregir defectos encontrados de los últimos Sprints. Si bien el dueño de la pila de producto es el usuario es necesario ver con él,  el incluir las actividades de investigación o trabajo técnico, el resto de las actividades son claras para el.  La pila de producto siempre debe estar visible para el equipo y con sus prioridades dado que se usan en las actividades de planeación. A medida que el desarrollo avanza la pila de producto se puede volver compleja y grande, por lo que podemos incluir la información que nos ayude a mantener en buen estado nuestra pila de producto. El ejemplo se puede descargar de Allsoft -> Recursos

El cliente en Scrum es vital, es parte del equipo, si no contamos con un compromiso claro del cliente que participara con el equipo a lo largo del desarrollo será mejor tomar otra alternativa. El cliente juega el papel del Producto Owner quien representa los intereses de la empresa y de los demás involucrados relevantes. Si el Product Owner no participa activamente el impacto en el proyecto es enorme considerando que en al menos 2 semanas el equipo debe entregar algo. El product Owner es dueño del Product Backlog, ve por la visión del producto y la transmite, está disponible en el transcurso del proyecto para cualquier duda, al final del Sprint revisa el producto vs los objetivos del Sprint y esteblece las prioridades para el siguiente Sprint. Como vemos existe mucha participación y que es vital para proder desarrollar el producto.

Si bien el Product Owner conoce de su necesidad o de la necesidad de los que representa, es necesario que pueda transmitir eso al equipo de Scrum. Debe de poder transmitir la Visión del producto y el valor del mismo para la organización. El Product Owner para tomar su rol debe de conocer como va a definir las historias de usuario o su necesidad, como va a participar en el proyecto, sobre sus responsabilidades, como debe de priorizar las historias, como debe de participar en las reuniones, que debe esperar de cada participación en el proceso y que se espera de él también. El Scrum Master debe de trabajar un poco con el Product Owner para prepararlo para su rol, no por que tenga conocimiento de la necesidad podrá expresarlo y trabajarlo con el equipo. Una buena práctica antes de iniciar con la primera planificación es tener alguna sesión con todo el equipo en donde se explique la visión y se vea un panorama general del producto, del contexto del mismo, las necesidades que quiere cubrir, etc.  Tener esto como antecedente hará mas dinámico el proceso de revisión de historias y la planificación