Comme d'autres réponses l'ont indiqué, la direction a parfaitement le droit d'obtenir une estimation de haut niveau en amont d'un projet. Ils ne sont pas déraisonnables pour essayer de déterminer le retour sur investissement.
Cependant, l'une des approches que j'aime chez Agile est que la portée d'un projet n'est pas fixe. Il peut être initialement dimensionné au niveau de la fonctionnalité et de l'épopée, puis les entreprises peuvent déterminer le retour sur investissement en fonction des fonctionnalités les plus importantes. L'interface utilisateur sophistiquée avec cloches et sifflets a peut-être une faible valeur commerciale, mais le moteur de flux de travail pour le traitement des réclamations a un retour sur investissement élevé.
Lorsque vous regroupez l'ensemble du projet, il est plus difficile de respecter le retour sur investissement que si vous vous concentrez sur les fonctionnalités commerciales essentielles souhaitées.
Voici une façon dont j'ai fait cela:
Prenez vos étapes WBS et transformez chacune d'elles en une fonctionnalité livrable
Cela vous permet de classer votre projet en mini-sous-projets dont la valeur commerciale varie. Chacun de ces éléments devrait être autonome en termes de valeur commerciale.
T-Shirt taille l'effort sur les fonctionnalités
C'est un moyen très simple d'avoir une idée approximative de la taille ou de l'implication d'une fonctionnalité particulière. Peut-être que les fonctionnalités de faible valeur ont toujours un excellent retour sur investissement si elles ressemblent à des gains faciles.
Décomposer une fonctionnalité en histoires
Parcourez l'exercice pour trouver une petite fonctionnalité bien comprise et décomposez-la d'abord en histoires. Estimez ces histoires par points. Maintenant, vous avez une base où
Petit -> 40 points
Ce sera une base de comparaison avec d'autres fonctionnalités
Associez l'effort du point d'histoire à toutes les fonctionnalités
Comparez votre petite fonctionnalité à d'autres fonctionnalités. Par exemple,
La fonction moyenne Y donne l'impression que c'est deux fois la taille et l'effort de la petite fonctionnalité X de 40 points d'histoire.
La caractéristique moyenne Y représente probablement 80 points d'histoire. Continuez jusqu'à ce que vous ayez des points d'histoire estimés à un niveau élevé pour toutes les fonctionnalités.
Estimez la vitesse de votre équipe
En regardant votre équipe de développement, essayez de déterminer combien de points d'histoire cette équipe pourrait-elle livrer efficacement dans un sprint donné. Si vous avez des projets Agile précédents comme exemple avec cette équipe, c'est un excellent point de départ. Si vous n'avez pas un tel historique derrière l'équipe, passez par une simulation de planification de sprint avec votre équipe où vous commencez à regarder votre petite fonctionnalité que vous avez détaillée. Quels types d'estimations horaires les gens donnent-ils pour leurs tâches sur ces histoires?
En fonction de la quantité de travail que l'équipe pense pouvoir réaliser en 2 semaines, utilisez ce nombre total de points d'histoire comme la vitesse potentielle moyenne de votre équipe!
Trouvez votre date d'achèvement prévue
Si votre équipe dans la planification d'un sprint simulé se sent à l'aise de livrer 25 points d'histoire dans un sprint, et que votre carnet de commandes total ressemble à 300 points d'histoire pour la version Cadillac or de votre projet, alors il semble que votre équipe prendrait idéalement 12 sprints ou 24 semaines pour tout compléter.
Maintenant, il est trivial de transformer le coût des ressources de votre équipe en dollars par semaine pour arriver à un coût pour le retour sur investissement par rapport à la valeur commerciale. La négociation peut se poursuivre sur les fonctionnalités les plus importantes, puis la gestion de votre projet devient fondamentalement un problème de sac à dos.