Cómo cambia el papel del Product Owner al aplicar Scrum en desarrollo de hardware
Scrum puede aplicarse al hardware si se adapta a su lógica física: Product Owner técnico, backlog por componentes e historias técnicas para definir entregables.
Resumen del artículo publicado en agilealliance.org y recomendado por Digital Skills Institute el 29 de agosto de 2026.
La adaptación de Scrum al desarrollo de hardware plantea cómo trasladar un marco muy extendido en software a entornos donde se diseñan productos físicos. La cuestión importa a quienes trabajan en ingeniería porque las diferencias entre ambos ámbitos afectan a la propiedad del producto, la forma de descomponer el trabajo y la planificación. La experiencia descrita procede de una transformación Scrum en una empresa biotecnológica que desarrollaba un nuevo espectrómetro de masas, y sirve para contrastar una idea previa: el marco Scrum puede funcionar bien en hardware, pero muchas prácticas habituales importadas del software necesitan cambios.
Una primera diferencia aparece en el papel del Product Owner. En el proyecto, esta función recaía en un físico que también participaba parcialmente en el trabajo de desarrollo dentro del equipo Scrum. Su papel no se limitaba a orientar el producto o priorizar necesidades, como suele ocurrir en equipos de software donde el Product Owner procede a menudo de gestión de producto o marketing. En este caso, hacía falta un conocimiento técnico muy profundo del interior del producto para tomar decisiones útiles y contribuir al avance del diseño. Esa combinación convertía su participación directa en ingeniería en una necesidad práctica.
Esta forma de ejercer la propiedad del producto tiene consecuencias organizativas. Un Product Owner de hardware suele tener capacidad para apoyar únicamente a un equipo Scrum, porque también dedica parte de su tiempo al trabajo técnico. En cambio, en software es más habitual que una misma persona dé soporte a dos o tres equipos si su función se centra sobre todo en gestionar prioridades y requisitos. Por ello, una organización de hardware puede necesitar más Product Owners que una organización de software de tamaño parecido.
La descomposición del alcance también cambia. En software se suele empezar por las experiencias de usuario que debe ofrecer el producto y, después, se identifican los elementos técnicos o infraestructurales necesarios para hacerlas posibles. El resultado acostumbra a ser una arquitectura por capas, donde cada historia atraviesa varios niveles técnicos como una porción vertical de la pila tecnológica. En el caso del espectrómetro de masas, los miembros del equipo podían identificar experiencias de usuario, pero no organizaban así su comprensión del trabajo pendiente.
Durante la planificación de la release, al preguntar por las partes principales del dispositivo y por cómo estructuraban mentalmente su diseño, surgió una lógica distinta: componentes físicos, ensamblajes y subsistemas. La experiencia de usuario no desaparecía, pero ocupaba un lugar secundario frente a la arquitectura física del producto. Incluso cuando se intentó reconducir la conversación hacia capacidades visibles para el usuario, esa vía no resultó útil para definir el alcance; el equipo volvió pronto a una descomposición orientada a componentes.
También varía el uso de historias. Se distingue entre Historias de Usuario, centradas en una experiencia que debe implementarse, e Historias Técnicas, que emplean una estructura similar con título, narrativa y criterios de aceptación, pero describen entregables técnicos y omiten el rol del usuario. Aunque algunas prácticas defienden usar solo Historias de Usuario e integrar cualquier trabajo técnico dentro de ellas, hay entregables que no encajan bien ahí; un documento de arquitectura es un ejemplo claro.
En este proyecto todas las historias acabaron siendo técnicas. El trabajo se definía alrededor de componentes, conjuntos y subsistemas del espectrómetro, no alrededor de interacciones con usuarios. Lo mismo ocurría con las épicas: mantenían el mismo formato general que las historias y solo se diferenciaban por su tamaño, ya que requerían dividirse antes de entrar en la planificación del sprint.
La redacción de historias siguió igualmente un patrón distribuido. En software suele esperarse que el Product Owner escriba la mayoría de Historias de Usuario y que el equipo redacte algunas Historias Técnicas puntuales. Aquí, al tratarse únicamente de épicas e historias técnicas y al estar gran parte del conocimiento repartido entre especialistas, la escritura se distribuyó entre el Product Owner y los miembros del equipo. Esa distribución evitó concentrar la carga en una sola persona y permitió avanzar con buen ritmo.
Las adaptaciones observadas responden a rasgos estructurales del desarrollo físico: gran parte del conocimiento necesario para definir y priorizar el trabajo reside en especialistas técnicos. Scrum puede conservar su utilidad en hardware si sus convenciones prácticas reflejan esa realidad: un Product Owner con profundidad técnica y participación limitada por equipo, un backlog descompuesto según arquitectura física y unas historias técnicas tratadas como principal artefacto para especificar entregables.
