Scrum: elementos técnicos en una cartera de pedidos gestionada por un PO no técnico.

Question

En caso de artículos técnicos como "Secuencia de actualización de v1 a v2" o "Aumentar el rendimiento de inicio" o "Refactorizar el módulo de inicio de sesión para reducir la complejidad del código", ingrese al registro de pedidos del producto. priorizarlos frente a otros elementos más atrasados ​​funcionales?

¿Debería haber una acumulación de tareas por separado? ¿Deberíamos tener un rol conjunto de PO con dos personas que puedan priorizar cosas funcionales y técnicas en la cartera de pedidos del producto?

Answer 1

he tenido éxito con el enfoque dual atraso:

1. acumulación del producto es propiedad del dueño del producto. Contiene elementos del nivel de la historia (características) que el equipo estima y luego prioriza por el propietario del producto. Este proceso de estimación divide las historias en tareas más pequeñas.

2. El backlog del equipo es propiedad del equipo de desarrollo. Contiene elementos de nivel de tareas que son relativamente pequeños (se pueden completar dentro de un sprint). Se pueden vincular a historias, por ejemplo, como impedimentos: para completar la historia, las siguientes tareas técnicas deben completarse primero. También pueden ser independientes, por lo que no son necesarios para ninguna historia en sí, pero pagan una deuda técnica para permitir una mayor velocidad en el futuro.

(En algunos programas grandes, multi-proyecto también he tenido retrasos de programas que contienen elementos de nivel épico, propiedad y priorizados por un equipo de gestión del programa, a dividir a las historias en los retrasos de productos más adelante.)

Answer 2

Por lo general, en el SCRUM 'vainilla' las tareas técnicas que mencionas no aparecerán como historias separadas.

Para mí, el PO no técnico no debería mirar las historias como 'Actualizar el servidor'. No es una historia comercial, no es visible para el usuario final, por lo que es difícil priorizar si está formulada de esta manera. Las prioridades se deben asignar de acuerdo con el valor comercial del trabajo. 'Actualizar' no significa mucho. "Permitir más conexiones simultáneas", "Reducir el tiempo de inactividad" o incluso "mejorar la velocidad del equipo" podría proporcionar información mucho más valiosa a una persona no técnica. Si no puede encontrar una descripción no técnica, hágase una pregunta sobre la necesidad de la actualización :)

La historia de la 'refactorización' es aún más complicada. ¿Te preguntaste por qué es una historia? La refactorización podría hacerse como una tarea en la historia, pero raramente es una historia en sí misma. Por lo tanto, si desea que el inicio de sesión funcione mejor o proporcione más funciones, esa es una historia, pero retocar bajo el capó no cuenta como tal. Tenga en cuenta también que la refacturación sin un propósito comercial podría conducir fácilmente a un llamado 'dorado'

Sugeriría hacer las historias de 'actualización' como un aumento con el 'rendimiento mejorado' y el 'factor de nuevo' las tareas para una historia empresarial relevante.

P.S. Puede encontrar una buena discusión sobre este tema (principalmente en la parte 3) en el excelente libro de Mike Cohn llamado "User Stories Applied: For Agile Software Development".

Answer 3

estoy de acuerdo con la visión de ver el beneficio del negocio de cualquier historia técnica y seguimiento que en la principal pila de producto

sí creo que hay historias internos relacionados con la velocidad/capacidad del equipo, el cual a veces se administran de manera más conveniente asignando cierta capacidad a los desarrolladores, especialmente cuando el Propietario del Producto no está interesado en priorizar o administrar esas historias. P. ej. Asigne un 10% de capacidad para probar la acumulación de automatización (de regresión heredada), configuración del servidor CI, etc.

Sí, todo puede expresarse en términos comerciales, pero parte debe considerarse "la forma en que necesitamos hacer nuestro trabajo "donde hay confianza entre el propietario del producto y el equipo de que el equipo hará un mejor uso de la capacidad asignada para esto.