Re: Choice modeling and Agile?
- While the emphasis on finding a dollar ROI for each feature may be an
idea to make the customer more aware of the resources she is spending,
I think that there is a risk to fall into the same legalistic trap
that traditional project management does when it treats estimates as
commitments and a schedule as a prediction.
It seems to me that the core purpose behind any prioritization is to
work on the most important things first. For this need, a ranking
gives you 90% of the value with 10% of the work.
Thus, I think that the discussion on "feature ROI" should be part of a
pep-talk in the initial project definition phase, with occasional
reminders during the planning game, but the tough work required to get
an actual ROI for each feature sounds non-agile in the sense that it
is "up-front work" that does not produce working code that the user
can actually approve. Since priority ranking is a cheaper alternative
that can get you to actual coding quicker, I would recommend keeping
feature-ROI as a conceptual construct and not a mathematical process.
In any case, if we go down this path, Agile would require having a
feedback process where you actually do testing to determine if your
calculations corresponded to reality, so that you could improve the
process on the next round. That sounds like a very long feedback loop
to me, and I wonder if the ROI is positive at all, and I certainly
think that most of our teams would find a higher ROI from implementing
or improving other aspects of our craft.