It is difficult to provide a formula for prioritizing the work to be done. On the surface, it may seem that we should, “Do what is most valuable to the users”, but that is often not the formula used and for good reason. Sometimes we must do a task for political reasons, because the boss demands it, or because we need to change the way this code works to make a particular person happy so that we can work with him better on other tasks. Sometimes it may be done because a client keeps asking about this one change.
Besides the political, you may choose to have a junior developer work on a feature even though it is not the most important thing he could work on. It could teach the junior developer a valuable skill. We want him to get better at Silverlight, and he could probably add this Silverlight feature, so we will have him add this to increase his skills. In this case, we are sacrificing the best feature now in order to make him a better developer so that as a team we have better options in the future.
A third reason for ignoring the next most important feature is that we include some of the lower priority features in with a high priority feature because the high and low priority features are all part of the same code base. Developers usually say, “While we are in that block of code, we might as well add these features…” This is often beneficial because the developer does not need to repeat the time invested understanding that section of code, and the overall testing time of the features may be reduced.
Are there other reasons that we work on features other than what is most valuable to the end users?
Rob Kraft's Software Development Blog 