¿Cuál es la mejor manera de administrar una hoja de ruta y una cartera de pedidos? Actualmente utilizamos JIRA y Confluence para la mayoría de la ‘gestión de proyectos’, pero estoy dispuesto a aventurarme con otras herramientas, si es que ayudan.

Hola, parece que ustedes están pasando por un mal momento. No estoy seguro de por qué decidió separar el trabajo atrasado de la hoja de ruta, pero me gustaría ofrecer una solución que realmente los una a la perfección: Craft

Craft es una plataforma de gestión de productos de extremo a extremo para equipos ágiles que le permite ver todo su proceso como un flujo simplificado: descubrimiento de características> definición del producto> planificación de la hoja de ruta y gestión de tareas con una cartera de pedidos que se conecta a la hoja de ruta. También nos integramos con JIRA, TFS, Google Drive, Dropbox, GitHub y pronto Sketch y Zapier.

Esto es lo que parece:

Una visualización flotante de una hoja de ruta en Craft >>

De la forma en que lo vemos, la única forma de administrar un trabajo atrasado correctamente es si usted tiene un control constante de su proceso general. Solo cuando tenga la imagen completa puede priorizar de una manera que tenga sentido y movilizar sus recursos de la mejor manera posible.

Comprendemos completamente la necesidad de ver su proceso en detalle junto con la necesidad de ver la imagen completa, por lo que estamos ofreciendo a los usuarios de Craft la capacidad de alternar entre las vistas. De esta manera, puede ver su proceso desde todos los ángulos posibles y tomar las decisiones más informadas sobre los próximos pasos.

Algunas otras vistas de la hoja de ruta de Craft >>

Hojas de ruta de múltiples productos >>

Priorización y gestión de ítems >>

Al igual que Cliff, tiendo a mantener una distinción clara entre una hoja de ruta estratégica de alto nivel y una cartera de pedidos más detallada. Sé que es más fácil decirlo que hacerlo, pero la palabra clave aquí es “valor”.

¿Cuál es el valor o el objetivo comercial o de usuario que está tratando de lograr? ¿Cómo se alinea una característica particular o corrección de error con dicho valor? Mi regla general es que si no puede articular un valor tangible para un elemento en particular, entonces no debería estar en su cartera de pedidos (¡y definitivamente no en su hoja de ruta!).

Crear una cartera de productos realista y manejable

El ejercicio de asignar un valor claro (comercial o de usuario) para priorizar un elemento de la cartera de pedidos me ha resultado realmente útil para mantener una cartera de pedidos de productos manejable. No cometa el error de tener cosas en la cartera de pedidos que no tienen un valor claro asociado o que es poco probable que se hagan. Tener una acumulación de trabajo ‘desordenada’ o interminable puede ser desmoralizante y puede conducir a una pérdida de concentración (como probablemente haya experimentado).

En cuanto a las herramientas de acumulación que podría utilizar, puede considerar uno de los siguientes:

• Plugin de Greenhopper para JIRA
• Rally Community o Enterprise Edition
• BacklogTool
• Una hoja de cálculo simple de Excel (es posible que desee consultar la publicación de Mike Cohn en la hoja de cálculo de Agile Excel para ver la cartera de productos)
• Un tablero Scrum o un tablero Kanban; Tener su cartera de pedidos y elementos en progreso en la pared de la oficina

Si usted y su equipo están luchando con su carga de trabajo, incluso una simple hoja de cálculo o post-it en la pared mostrará rápidamente que se está ahogando.
Descubrí que cuanto más visible es algo (como en un tablero Scrum o Kanban), es más fácil explicar a las personas cualquier cuello de botella o carga de trabajo poco realista.

Igualmente, como gerente de producto que utiliza un tablero Scrum o Kanban, debería poder demostrar con bastante facilidad cómo se puede reducir la carga de trabajo o cómo se puede recuperar el enfoque del equipo.

Crear y administrar una hoja de ruta del producto

Cuando el trabajo atrasado es un desglose detallado de características específicas o correcciones de errores, la hoja de ruta es un documento más estratégico y de alto nivel. En mi experiencia, una hoja de ruta actúa como una guía importante para los objetivos clave que una empresa está tratando de lograr. He visto personas que usan hojas de ruta como una mezcolanza de características, tratándolas casi como una lista de deseos. Supongo que la señal de una buena hoja de ruta es cuando puedes combinar ‘temas’ u objetivos estratégicos clave con esas características de alto nivel que te ayudarán a lograr los objetivos establecidos.

Como gerente de producto, realmente puede usar su hoja de ruta para enfocar las mentes y las aspiraciones de sus partes interesadas. ¿Cuáles son nuestros objetivos comerciales clave y por qué? ¿Se pueden medir y probar estos objetivos? ¿Qué productos o características clave son críticos si queremos cumplir nuestros objetivos?

En cierto modo, acordar estas cosas es más crítico que los productos o características reales en los que usted y su equipo están trabajando. Las prioridades del producto siempre pueden evolucionar (por ejemplo, debido a las condiciones cambiantes del mercado o nuevas oportunidades), pero todos en su organización se beneficiarán de una dirección estratégica clara.

Además, cada vez que se pregunta “¿deberíamos hacer esta función o no?” o “¿qué trabajo debo priorizar y por qué?” tienes un marco claro para responder esa pregunta. Roman Pichler ha escrito una publicación de blog muy útil en la que explica más sobre Trabajar con una hoja de ruta de productos ágiles y destaca las diferencias entre una hoja de ruta y una cartera de pedidos.

Afortunadamente, con una hoja de ruta de producto clara y realista, debería resultarle más fácil crear y administrar una cartera de productos mucho más ‘simplificada’ y alcanzable.

Tienes razón: ¡JIRA es fantástico para el desarrollo, y deberías conservarlo! Pero JIRA definitivamente no estaba destinado a administrar una cartera de pedidos o la hoja de ruta de su producto.

Lo que necesita es una herramienta de gestión de productos como ProdPad.

ProdPad le permite administrar su cartera de pedidos y vigilar cosas como las tendencias, los votos de su equipo, el impacto, el esfuerzo, el tiempo, las ganancias rápidas e incluso maneja los comentarios de los clientes, lo que le permite concentrarse en todas las cosas correctas. En lugar de solo lidiar con una lista estática como con JIRA, realmente puedes visualizar tus prioridades, un poco como esto:

Lo que está viendo en el cuadro anterior son todas las ideas con impacto y esfuerzo, trazadas entre lo que llamamos sus ‘Ganancias rápidas’ y sus pérdidas de tiempo.

El tamaño del punto indica qué tan bien especificó una idea (¡ya sea una línea o incluye información como un caso de negocios!) Y el color indica cuándo fue la última vez que interactuó. Es absolutamente la mejor manera de visualizar la antigüedad de sus ideas, y probablemente podría identificar rápidamente cuáles han envejecido, por así decirlo.

A medida que pasa sus ideas a través de sus propios flujos de trabajo, puede decidir cuáles llegarán a la hoja de ruta.

Y hablando de hojas de ruta …

Una hoja de ruta del producto debe ser visual , accesible y lo suficientemente clara para que cualquiera pueda buscar respuestas a las siguientes preguntas:

• ¿Que estamos haciendo?
• ¿Por qué lo estamos haciendo?
• ¿Cómo se relaciona esto con nuestros OKR?

Es posible que esté familiarizado con una hoja de ruta que incluye una lista de características y su fecha de finalización esperada.

Una hoja de ruta basada en temas, como la nuestra, reemplaza eso con temas (¡lo adivinó!), Que se encuentran en su hoja de ruta como tarjetas.

Los temas son “una promesa para resolver problemas, no para construir características”, dice el fundador de User Interface Engineering Jared Spool.

Esas palabras provienen de la comprensión de que para casi cualquier producto, tendrá una avalancha de comentarios y solicitudes de características de clientes que realmente giran en torno a un único problema universal.

¡No dude en visitarnos y contestar cualquier pregunta!

Lo más importante que debe buscar en la gestión de la cartera de pedidos es una forma de priorizar claramente todo en lo que los equipos puedan trabajar en una vista única y coherente. Al contrario de lo que mucha gente quiere pensar, en un equipo pequeño
todo está compitiendo por los recursos: errores, mantenimiento, funciones, trabajo personalizado, etc. Pasamos un par de meses buscando una herramienta que funcionara tanto para nuestro equipo de gestión de productos como para nuestro equipo de desarrollo, y terminamos decidiéndonos por Countersoft Gemini como la solución implementamos No es perfecto, pero la capacidad de “Zona de secuencia” fue, con mucho, la mejor herramienta de priorización de tipo cruzado que encontramos.

En cuanto a la separación de su cartera de trabajo y la hoja de ruta, la recomendación que le daría es centrar su “hoja de ruta” en los temas y los plazos del mercado (ferias, eventos de mercado, etc.) y no en las minucias. Use “carriles de natación” y muestre líneas de tiempo generales, no estimaciones específicas. La hoja de ruta es solo eso: una guía; si eres realmente “ágil”, entonces sabes que surgirán cosas y el plan tendrá que ser ajustado.

Hola. Mucho gusto: hay muchas cosas allí, pero lo que usted describe es una situación muy familiar para mí. Este fue un punto de dolor tan grande en mi última compañía de software, que creamos Receptive para resolverlo.

He abordado cada uno de sus comentarios a continuación:

“Antecedentes: soy gerente de producto y tengo problemas para administrar nuestro trabajo atrasado para un producto que tiene muchas partes interesadas, clientes, errores, solicitudes de características operativas únicas y grandes iniciativas estratégicas (características más grandes). El producto y el equipo técnico difícilmente pueden mantener su cabeza fuera del agua con los errores y el soporte operativo, y mucho menos las nuevas solicitudes de características “.

Esta es una situación tan difícil de manejar, totalmente de acuerdo. Receptivo reúne solicitudes de funciones priorizadas de todos los interesados ​​que ha mencionado. Luego, nuestros informes segmentan todos los datos para que pueda ver exactamente lo que es importante para cada grupo y así poder tomar decisiones de productos basadas en datos. Más información aquí. Es vital que establezca un buen proceso y comience a reunir todas estas solicitudes en un solo lugar para que pueda actuar sobre toda la información que está recibiendo.

“¿Cuál es la mejor manera de administrar esta cartera de pedidos? Me estoy dando cuenta de que un trabajo atrasado y una hoja de ruta deben estar separados, pero me está costando unir los dos a la vista de los ejecutivos ”.

Sí, estoy totalmente de acuerdo. Estos deben estar separados. Con Receptivo, todas las solicitudes de funciones priorizadas se reúnen en un solo lugar para que usted pueda administrar las solicitudes con mucha facilidad. A medida que mueve una función a “Planificado”, por ejemplo, se agrega automáticamente a la hoja de ruta de su producto. Básicamente, todo el proceso está automatizado, eliminando todo el trabajo manual de su plato. Hay un video sobre el flujo de trabajo disponible aquí.

“¿Cuál es la mejor manera de demostrar que nos estamos ahogando?”

¿Tiene un gerente o alguien en el equipo de liderazgo al que pueda informar? No hay forma de que deba lidiar con todo esto por su cuenta. Parece que es hora de poner en marcha un proceso sólido. Si aprovecha los datos de solicitud de funciones correctamente, impulsará el crecimiento de su empresa.

“Actualmente utilizamos JIRA y Confluence para la mayoría de ‘gestión de proyectos’ pero estoy dispuesto a aventurarme a otras herramientas si pueden ayudar”.

JIRA & Receptive es una combinación perfecta. Mira aquí. El complemento JIRA de Receptive es una integración bidireccional y lleva unos minutos configurarlo. Esto ha tenido enormes beneficios para nosotros. Es genial poder cambiar el estado de una función a “Planificado” y luego hacer que la integración se encargue del resto. Nos brinda una comunicación fluida entre el producto y el desarrollo y los PM especialmente adoran cómo siempre saben lo que ha lanzado el equipo de desarrollo.

Me encantaría hablar más sobre cómo podemos ayudar. Puedes contactarme en [correo electrónico protegido]

¡Buena suerte!

Considere cuidadosamente lo que es estratégico y lo que es táctico.
– El desarrollo estratégico le dará a su organización (y a sus clientes) una ventaja competitiva a largo plazo sobre la oposición. Es la propiedad intelectual (IP) lo que les resultará difícil de replicar e impulsarán el crecimiento a largo plazo de sus productos. Permite tendencias futuras (políticas, económicas, sociales, tecnológicas) dentro de ciclo de vida general del producto y el de la cartera de productos más amplia.

– El desarrollo táctico impulsa los objetivos de ingresos a corto plazo. Soluciona problemas inmediatos, ayuda a retener la base actual de clientes y promueve las ventas. El desarrollo táctico generalmente puede ser fácilmente replicado por la competencia y, por lo tanto, no proporciona ganancias a largo plazo.

Tenga en cuenta que esto no se trata del tamaño de una tarea; Las “epopeyas” pueden ser estratégicas o tácticas.

Mira hacia atrás a través de tus Sprints
¿Cuánto de los últimos 20 Sprints se gastó en trabajo táctico? ¿Cuánto en estratégico? Use las estimaciones de puntos de la historia como guía.

Cree un modelo y úselo para priorizar
Estamos avanzando hacia 50/50, es decir, la mitad de un ciclo general de “lanzamiento” (digamos 6 meses) se gastará en desarrollo estratégico y la otra mitad en táctica. También estamos avanzando hacia 50/50 en épicas, es decir, la mitad de un ciclo de lanzamiento se gastará en épicas y la otra mitad en otras historias de usuarios

Si llega a una recesión económica, es posible que deba ayudar a “defender” la competitividad de su cliente en el corto plazo y agregar “complacer a la multitud”, de modo que cambie el equilibrio del desarrollo estratégico a táctico.

1. “Actualmente utilizamos JIRA y Confluence para la mayoría de ‘gestión de proyectos’ pero estoy dispuesto a aventurarme a otras herramientas si pueden ayudar”.

No necesitas una herramienta diferente. JIRA puede satisfacer sus necesidades.

2. “¿Cuál es la mejor manera de demostrar que nos estamos ahogando?”

¿Estás rastreando la “velocidad”? Si no, tienes que hacerlo. Siempre me sorprende cuántas empresas no hacen esto. Tuve que introducir esto en mis últimas tres empresas. Esto es critico. Los ejecutivos son influenciados por números, hechos, históricos. Debe poder mostrarles “oferta frente a demanda” en términos que puedan entender. (Si usa puntos, es posible que necesite traducirlos a algo más concreto como “días de hombre” para consumo ejecutivo).

3. “Me estoy dando cuenta de que un trabajo atrasado y una hoja de ruta deben estar separados, pero me está costando unir los dos a la vista de los ejecutivos “.

Este es un comentario crítico y es la raíz de su desafío: el trabajo atrasado y la hoja de ruta son independientes pero dependientes. La hoja de ruta debe ser una “vista” separada del trabajo atrasado, pero NO debe estar “separada” del trabajo atrasado.

4. “Tengo problemas para administrar nuestro trabajo atrasado para un producto que tiene muchas partes interesadas, clientes, errores, solicitudes de características operativas únicas y grandes iniciativas estratégicas (características más grandes)”.

Sí, estado allí, visto eso. Necesitas “agrupar” más las cosas. Aquí hay un marco que he usado en Jira:
1. Desarrollo de funciones grandes : principalmente historias, pero podría contener tareas y errores. Estos artículos están vinculados a iniciativas estratégicas, partes interesadas, clientes, etc. Tácticamente en Jira, estos deberían estar en una épica . (¿Utiliza Epics? Si no, debería hacerlo). Es posible que tenga una Epic para cada Stakeholder, Customer o Initiative. También es posible que necesites cambiar la fase o el tiempo de tus Epics para que puedas rastrearlos, por ejemplo, Customer X Phase 1, Q1 o Jan.

2. Mejoras : estas son Historias o Tareas que no están vinculadas a lo anterior (no están vinculadas a una Épica). Si lo desea, puede crear una Epic llamada Mejoras como un depósito para rastrear estos elementos.

3. Mantenimiento : se trata principalmente de correcciones de errores, pero también podría contener tareas.

5. “El producto y el equipo técnico difícilmente pueden mantener su cabeza fuera del agua con los errores y el soporte operativo, y mucho menos las nuevas solicitudes de características”.

Una vez que comience a rastrear la velocidad por los cubos anteriores, se sorprenderá de cuán poca de su capacidad se destinará al n. ° 1 (por ejemplo, “permitir nuevas solicitudes de características”. En una de mis últimas empresas era del 50% en promedio, pero disminuiría ¡hasta un 25% en ocasiones cuando los problemas de calidad o las quejas de los clientes aumentaron!

Si está rastreando la velocidad, pero no tiene depósitos, ejecute una consulta simple: observe todos los “problemas” completados en los últimos meses por tipo de problema . ¿Qué porcentaje son historias? ¿Bastante bajo, apuesto? Este es un buen proxy. Si no está rastreando la velocidad o los puntos, solo haga un porcentaje por conteo, por ejemplo, suponga que cada problema vale 1 punto.

Debe poder mostrar estos datos para mostrarle a la gerencia cómo se está gastando su capacidad (cómo la demanda excede la oferta y qué tan abrumado está su equipo). El problema con la mayoría de las empresas es: 1. no están rastreando la velocidad y 2. no han creado cubos de alto nivel que los ejecutivos puedan entender. Por lo tanto, los ejecutivos suponen que tienen el 100% de la capacidad de ingeniería para el Desarrollo de características, y los planes y hojas de ruta se crean utilizando esa suposición, y los equipos de ingeniería reciben una F * cked.

Resumen
En resumen, debe crear más jerarquía en Jira. ¿Cómo se come un elefante? Un bocado a la vez. Necesita una acumulación, pero debe poder “enrollarla”, “perforarla” y “cortarla y cortarla en dados”. Necesita crear varias “vistas”. Uno para consumo ejecutivo y priorización, y otros para varios equipos y gestión diaria. Jira no es buena en la jerarquía, pero puede hacerlo ahora y está mejorando. ¿Ha comprobado las nuevas capacidades de gestión de cartera? Todavía no lo he usado, pero se supone que ayuda con algunos de estos desafíos.

Fuera de la caja, Jira tiene esencialmente 4 niveles de jerarquía natural:
1. Proyecto (que creo que es un nombre inapropiado)
2. épico
3. Historia / Tarea / Error
4. Subtarea (hijo a historia / tarea / error)

Debe aprovechar estos niveles para habilitar el despliegue y la profundización y ayudarlo a administrar su cartera de pedidos. Las subtareas son generalmente muy poco utilizadas. Las personas a menudo son flojas y crean una Tarea versus crear una subtarea para una Historia. Utilice también los proyectos con cuidado, ya que mover problemas entre proyectos requiere “mover” los tickets. Los proyectos pueden tener diferentes flujos de trabajo y metadatos, por lo que mover tickets entre proyectos debe ser poco frecuente en la OMI. Los proyectos deben estar alineados con los equipos de funciones cruzadas de la OMI. Algunas veces esto significa un Proyecto para toda una organización de Ingeniería o un Proyecto por Iniciativa Estratégica. Generalmente he usado el campo Componente para rastrear equipos de componentes, pero ahora también hay un campo Equipo. También he agregado los campos “Estrategia” y “Producto” a veces. Sin embargo, el uso de campos no es ideal, ya que esto crea una dependencia en la entrada de datos. Cosas como Epics, puebla estos datos automáticamente cuando arrastra el problema a ese cubo.

Queríamos hacer lo mismo en las últimas seis compañías de software y nunca encontramos una buena solución. Entonces, salimos y lo construimos.

Si está buscando una herramienta para construir un excelente software que esté bellamente diseñado, realmente se beneficiaría de una herramienta de planificación de software especialmente diseñada como Aha!

Permite a los equipos administrar tanto una hoja de ruta como una cartera de pedidos al mismo tiempo. Echa un vistazo a algunas capturas de pantalla de lo que Aha! puede hacer para equipos ágiles.

Captura de pantalla de la hoja de ruta de la cartera

Captura de pantalla del tablero de planificación (tenga en cuenta el estacionamiento para administrar su cartera de pedidos)

Captura de pantalla de planificación de sprint

Captura de pantalla de la planificación estratégica.

Si estás interesado en aprender más sobre Aha! Hay una prueba gratuita de 30 días disponible en nuestro sitio web. Puede ver cuán fácil es administrar tanto su hoja de ruta como una acumulación de funciones en una sola herramienta de administración de productos.

Como es habitual en el desarrollo de software ‘Agile, la respuesta son prácticas más inteligentes en lugar de más herramientas.

Estamos usando, y ayudamos a otros a usar, mapas de impacto para objetivos y epopeyas / capacidades y mapas de historia para hoja de ruta.

Cuando tengo múltiples partes interesadas, también uso prácticas Lean. Por ejemplo, un tablero kanban en toda la organización, que cubre el flujo de valor completo es muy útil en las conversaciones.

Kanban aplicado correctamente le dará un tiempo predecible con poca o ninguna estimación. Los mapas de impacto enfocarán a las partes interesadas y al equipo en una meta. Los mapas de historias mostrarán el progreso en ese objetivo. Por lo tanto, toda negociación y facilitación de los interesados ​​será más simple.

Por otro lado, los equipos deben seguir mejorando para reducir el tiempo del ciclo. Por ejemplo, si hay muchos errores, el equipo necesita descubrir cuáles son las causas raíz y adoptar prácticas que los eviten. Muy a menudo, la falta de definición de hecho y definición de listo, o no seguirlos, crea tales problemas.

Espero que ayude.

Como han dicho otros, no se trata tanto de las herramientas como de su estrategia. Para mostrar a los ejecutivos que se está ahogando en el mantenimiento, debe medir el esfuerzo de mantenimiento de su equipo frente al esfuerzo de mejora y compartir las métricas de forma regular. Podrías hacerlo sincronizado con tus sprints, o si eso es demasiado frecuente, haz tres o cuatro sprints, o mensualmente, dependiendo de cómo captures los datos. Si su gente hace partes de horas, ¿puede hacer que clasifiquen su tiempo entre mantenimiento y mejora? No me refiero a ingresar el tiempo para cada artículo empaquetado (eso sería muy malo), pero en el transcurso del día divida su tiempo entre el tiempo que pasó reparando errores en lugar de trabajar en una nueva función. También debe clasificar sus artículos empaquetados. Todos los errores son mantenimiento, pero algunos elementos de la cartera de productos también son mantenimiento (por ejemplo, actualizar un control integrado). No hay hojas de tiempo? Use puntos de la historia, o traduzca en algo que resuene con los ejecutivos, como (me atrevo a decirlo) horas. Como ejercicio, si tiene una manera de calcular el tiempo real por punto de la historia, hágalo y vea lo que obtiene. Incluso si su equipo está utilizando un punto de historia del “día ideal del desarrollador” (punto de la historia = 8 horas, o 6 horas, o algún día “estándar”), el resultado puede sorprenderle. De los cinco equipos que superviso, el promedio de puntos por hora real más bajo es de 10.

Estoy de acuerdo con los demás en que su hoja de ruta y la cartera de pedidos de su producto son dos cosas diferentes pero relacionadas. Cada Epic (o Característica, según el marco que utilice) en su cartera de pedidos debe manifestarse en su hoja de ruta. Si no es así, ¿por qué está en su cartera de pedidos? Pero también debe medir el volumen de elementos y errores de la cartera de pedidos de productos en su cartera de pedidos que no están relacionados con las características / epopeyas de la hoja de ruta. Muestre a sus ejecutivos esa proporción, que sospecho que será alta a favor de los elementos no asignados. Prepare su cartera de pedidos, o esta medida no tiene sentido.

Tenga mucho cuidado de no cargar sus características / epopeyas. Estas iniciativas de nivel superior deben planificarse y definirse antes de comenzar a trabajar. Tienen un marco de tiempo en su hoja de ruta, ¿verdad? Entonces, si, una vez que comienzas con una, agregas más historias porque están relacionadas y solo piensas en ellas, o si ya estaban en la cartera de pedidos, sopas el alcance y, muy probablemente, el cronograma. Sé que eso suena antitético a la flexibilidad del scrum: todo el punto es poder cambiar en función de los comentarios sobre la entrega parcial. Pero lo que quiero decir es, asegúrese de que está manejando un cambio deliberado, no permitiendo el arrastre del alcance o el chapado en oro. De lo contrario, esa característica de cinco sprints terminará tomando diez sprints. Esta es también la razón por la que no estoy a favor de crear una función / épica “Corrección de errores del cliente” y poner todos esos elementos en ella. Esa es una característica interminable y, en última instancia, será desmoralizante para ti y cuestionada por tus ejecutivos. Su lado de servicios al cliente de la casa probablemente puede ayudarlo a empaquetarlos en productos más granulares, como “las demandas del cliente XX de actualización”, si debe empaquetarlos en características / épicas. Pero recomiendo usar etiquetas para acorralarlos. Una característica / épica debería tener un caso de negocios. Un paquete de correcciones de errores no lo hace.

Trabajo con Hansoft y esta es una de las preguntas más comunes que recibimos. Administrar la cartera de productos en Jira puede convertirse fácilmente en una tarea difícil en grandes producciones, ya que puede convertirse fácilmente en una larga lista plana de artículos.
El objetivo debe ser que el trabajo atrasado y la hoja de ruta sean las mismas cosas, de lo contrario será una doble contabilidad donde ninguno de los dos va a decir toda la verdad. Sin embargo, existe la necesidad de visualizar el trabajo acumulado en diferentes niveles.
Por ejemplo, los ejecutivos podrían estar interesados ​​en el lanzamiento de una determinada característica importante, mientras que un equipo podría estar interesado cuando se desarrolle una historia (componente) que están esperando.
Es por eso que será difícil hablar de una lista plana de elementos y llevarlo a crear diferentes versiones de la cartera de pedidos.

En esta página puede encontrar muchos recursos sobre cómo Hansoft puede ayudarlo a administrar su cartera de pedidos:
Herramienta Hansoft Agile | Vídeo

Especialmente le recomiendo que vea el video general: Introducción a Hansoft

Todas las demás respuestas parecen ser adecuadas para responder a su pregunta. Sin embargo, si hay participación de UX y expectativas extremadamente exigentes por parte de los clientes, podría considerar esta regla general:

La interfaz de usuario, la copia y el diseño gráfico deben completarse antes de que se escriba el código correspondiente.

Hay más información en esta publicación de blog, que describe algunas ideas potenciales para hacer que el diseño funcione con agilidad: el diseño está cambiando ágilmente para mejor.

Mi éxito en la gestión de la cartera de pedidos y la hoja de ruta se produjo cuando dirigí la conversación hacia las metas u objetivos comerciales, y centré los derechos de decisión de las partes interesadas en qué metas en qué parte y en qué plazo. Luego, como propietario del producto o arquitecto funcional, he utilizado el trabajo atrasado para proponer qué historias cumplen los objetivos.

La forma en que las historias apoyan los objetivos es una conversación importante con las partes interesadas. Pero los objetivos operativos y los problemas de calidad (errores) son objetivos en sí mismos, generalmente en alguna categoría, como mejorar la satisfacción del cliente o la rentabilidad, y alguien (tal vez no las partes interesadas) tiene derechos de decisión sobre las nuevas capacidades frente a la mejora del servicio.

Cada sprint / lanzamiento tendrá una combinación de objetivo de parte interesada, mejora operativa y reparación de calidad. Como gerente de producto, tendrá que gestionar las expectativas, y eso significa que las partes interesadas y sus ejecutivos también.

Lo que lo hace sentir como si estuviera bajo el agua es que el equipo no está haciendo sus compromisos o que las expectativas de las partes interesadas no se están cumpliendo. No estoy seguro de que tener un mejor trabajo atrasado o un proceso de hoja de ruta sea el problema. El proceso por el cual se rigen los compromisos es más probable que sea el culpable.

Una cosa que he encontrado con el equipo técnico sintiéndose “abrumado” es que han dejado de funcionar en secuencia. Cuando comienzan nuevas historias de la acumulación de sprint antes de que hayan corregido errores en historias antiguas. Terminan con demasiado trabajo “en progreso” y luchan por priorizar. Eso es realmente un problema de scrum master. Si su reserva de sprint y sus publicaciones de lanzamiento están secuenciadas, y el equipo trabaja en secuencia, no deberían sentirse bajo el agua. Simplemente están entregando menos historias de las anticipadas.

El equipo técnico o de entrega no debe centrarse en la hoja de ruta o el trabajo a largo plazo. El equipo de producto debe centrarse en las decisiones de sprint adelante o lanzamiento adelante, principalmente protegiendo al equipo de entrega para que puedan enfocarse en la decisión actual de sprint y lanzamiento.

Lo que esto puede requerir es la construcción de puntos de vista específicos para apoyar a cada audiencia relacionada con el equipo del producto, el equipo de entrega y las partes interesadas para que los líderes (gerente de producto, propietario del producto, scrum master) puedan enfocar la conversación con cada audiencia en torno a lo que tienen decisión derechos sobre. No conozco ninguna herramienta que le proporcione eso de forma inmediata, porque cada organización distribuye los derechos de decisión de manera diferente. Pero sé que Jira (y probablemente todas las otras herramientas enumeradas en las publicaciones a continuación) le permiten definir vistas o exportaciones que le permitirán hacer exactamente eso.

No estoy seguro de qué quiere decir exactamente con “hoja de ruta”, ya que no es oficialmente parte de ningún canon ágil formal. ¿Creo que te refieres a ideas de muy alto nivel sobre un producto? Es probable que sean “épicas” y se describan en un nivel probablemente vago en la cartera de pedidos del producto (recuerde que el PB puede tener otras cosas además de las historias de los usuarios, el PO puede poner lo que quiera allí).

Y recuerde, el PO trabaja en la cartera de pedidos del producto, el equipo trabaja en la cartera de pedidos de Sprint, ¿tal vez ahí es donde está confundido? Le expliqué la diferencia aquí: Producto versus retraso de Sprint

Grandes respuestas aquí ya, así que me gustaría agregar algo en el espacio de valor y trazabilidad. Gojko Adzic (quien nos dio la especificación por ejemplo) publicó recientemente su libro Impact Mapping, que describe una forma en que los propietarios de productos pueden comenzar a priorizar y vincular características con un valor medible.

Esta técnica ya ha demostrado ser útil en mi papel como cuidador de la cartera de solicitudes de una gran cantidad de aplicaciones comerciales para una variedad de partes interesadas.

Al observar los impactos que sus ejecutivos quieren lograr, puede obtener una clara priorización y validación de la hoja de ruta de capacidades, que luego puede usar para limitar su WIP para detener el ‘ahogamiento’ 🙂

Si un elemento de la cartera de pedidos no admite una capacidad elegida para lograr el impacto prioritario, ¿debería hacerse ahora?

Haga que su hoja de ruta del producto aborde los “objetivos del cliente” (con Job Stories), mientras que su cartera de pedidos está llena de “soluciones técnicas” (con User Stories).

---

Es mucho más importante construir lo correcto, en lugar de simplemente crear software rápidamente.

¿Pero cómo se definen los objetivos? Póngalos en una hoja de ruta del producto.

Es una mezcla de lo que ayudará a hacer crecer su producto (por ejemplo, más ingresos, más usuarios, etc.) y ayudará a sus clientes a alcanzar sus propios objetivos (puede encontrar y definir estos objetivos con Job Stories ).

En Blossom , almacenamos nuestra hoja de ruta de marketing de productos en un documento de Google.

Las soluciones técnicas, que forman la cartera de pedidos, se pueden expresar en el formato de historia del usuario .

Hay múltiples soluciones para lograr cualquier objetivo. Asegúrese de crear soluciones y priorizar la que resolverá los objetivos de su usuario (definida en la historia del trabajo).

En Blossom , ponemos características que sabemos que desarrollaremos en nuestro tablero Kanban.

Al separar la hoja de ruta de su producto y la cartera de pedidos en función de los objetivos frente a las soluciones, evita que su cartera de pedidos se convierta en un “cubo de todo” .

Si tiene una gran cartera de productos compleja, es casi imposible de administrar a menos que esté bien organizada. Mi sugerencia es que, si aún no lo está haciendo, debe usar epopeyas y temas para organizar su cartera de pedidos.

Las epopeyas y los temas tienen dos propósitos diferentes. Las epopeyas proporcionan una organización funcional jerárquica para agrupar historias de usuarios por funcionalidad y ayuda a comprender las interrelaciones e interdependencias. En lugar de tratar de administrar cientos o quizás miles de historias de usuarios individuales, es mucho más fácil administrar una cantidad mucho menor de epopeyas.

Los temas se pueden usar simultáneamente con las epopeyas para una variedad de cosas diferentes, como indicar la alineación con una necesidad particular de los interesados, la alineación con un objetivo comercial estratégico o casi cualquier otra cosa que desee rastrear y administrar.

Para retrasos grandes y complejos; Es casi imposible hacerlo manualmente sin las herramientas adecuadas, pero Jira tiene la capacidad de hacerlo. No he usado a Jira en algún momento, pero, según recuerdo, puede requerir un complemento para ayudar a estructurar y organizar su cartera de pedidos de esta manera. Otras herramientas ágiles admiten esta capacidad “fuera de la caja”.

Chuck Cobb
Autor de “La guía del administrador de proyectos para dominar Agile”
Echa un vistazo a mi capacitación en línea gratuita en http: // agileprojectmanagementaca …

El objetivo de la hoja de ruta es proporcionar una visión: ¿qué producto estamos construyendo? Con el tiempo, ¿qué escenarios vamos a habilitar?

El propósito del trabajo atrasado es proporcionar una lista de elementos en los que vamos a trabajar para completar la visión.

El propósito del plan de sprint es proporcionar una lista de los elementos en los que vamos a trabajar para este sprint.

Si cree que administrar la lista de tres es una carga, le sugiero que intente simplificar las dos anteriores, mientras solo mantiene el plan de sprint en detalles.

Básicamente, puede intentar hacer la hoja de ruta a alto nivel para que no sea necesario hacer ajustes frecuentes.

Luego, también puede simplificar el trabajo atrasado para que solo contenga características grandes que no se hayan hecho.

En el desarrollo de software ágil, la documentación y la gestión de procesos deben ser fáciles de administrar.

A riesgo de aparecer como autopromoción, diré que necesita una herramienta que combine sus planes a corto y largo plazo sin problemas, y eso es justo lo que ofrecemos en Gigantt: Scrum con Gigantt

El concepto es planificación “telescópica”. Planea tus sprints en alta resolución, por lo que obtienes estimaciones realmente confiables de cuánto puedes lograr en un sprint, pero también utilizas el mismo “plan” para catalogar tus objetivos a largo plazo. Debido a la forma en que está diseñada nuestra interfaz de usuario, con un gran enfoque en hacer que sea realmente fácil mover las tareas y difuminar las líneas entre ideas / historias de uso y tareas reales, puede satisfacer ambas necesidades: la alta gerencia debe tener un “Gantt” actualizado constantemente de la hoja de ruta a largo plazo, y los desarrolladores pueden centrarse en hacer las cosas con metodologías ágiles.

Encontramos que muchas organizaciones tienen esta tensión inherente cuando se trata de planear versus trabajar. Los gerentes y la gente de productos desean estimaciones a largo plazo debido a los objetivos comerciales, presupuestos, etc. y, por otro lado, los equipos de desarrollo se dan cuenta de que planificar demasiado con anticipación es inútil, ya que los requisitos cambian constantemente, etc. Esto dificulta que algunas organizaciones adopten un enfoque ágil metodologías porque los tomadores de decisiones se quedan sin las herramientas que esperan tener. Necesitan planificar el crecimiento, la contratación, los compromisos con terceros, etc., y no pueden hacerlo si los únicos puntos de datos que tienen son el sprint actual y la enorme acumulación de “cosas” que realmente no están bien pensadas . Al administrarlo todo en un solo lugar (en Gigantt básicamente trabajas en un gran plan de trabajo con potencialmente miles de tareas usando una interfaz de usuario de zoom) puedes difuminar las líneas entre estos dos “campamentos”.

También hace que sea mucho más fácil comunicar las estimaciones de esfuerzo. En lugar de suposiciones descabelladas de que luego tiene que negociar con la alta gerencia, puede profundizar en cualquier historia / épica y eliminar todo el trabajo oculto que generalmente se ignora por adelantado. Cuando se trata solo de un número, por ejemplo, “3 semanas”, es natural que las personas regateen, y eso es terrible para la organización porque confunde la estimación con el compromiso. Pero cuando esa cifra de “3 semanas” es en realidad una estimación agregada de 50 pequeñas tareas que pasó 10 minutos desglosando, es mucho más difícil argumentar. Menos tensión, menos regateo.

Esa es la forma en que lo hacemos internamente en Gigantt (y, naturalmente, comemos nuestra propia comida para perros …) 🙂