Prioritizing Use Cases in an Iteration

As part of an IBM Rational training on Requirements Management which I regularly deliver at Info Support, is an exercise aimed at prioritizing a set of requirements.

In that exercise, students are asked to prioritize a set of requirements giving a set of requirements attributes (all valued High, Medium or Low):

• Customer priority
• Risk
• Effort
• Stability

Arguements for prioritizing given by the students are along the lines of:

• All other attributes being equal, requirements with High Customer priority are done first,
• All other attributes being equal, requirements with High Risk are done first,
• All other attributes being equal, requirements with Low Effort are done first,
• All other attributes being equal, requirements with Stability High are done first,

The whole issue to be discussed in the exersise is: what is considered most important? Customer priority, or Risk, or Effort, or Stability?
All student groups score differently for different requirements, so at the end of the exercise we discuss the different outcomes.
I suggest the students to do exactly the same with their stakeholders in their projects and follow the next steps:

• During this discussion in the project, first look for commonalities: which requirements are top priority for all stakeholders?
  These requirements are set aside one by one, having the effect that one requirement at a time, the agreement between stakeholders on a significant part of the prioritation becomes apparent.
• Next pick requirements that were given high priority by some stakeholders, and low by others. For each of these requirements, ask the individual stakeholders to clarify their choice. Very often, when stakeholders look again at their priorities, they find out they made a mistake, acknowledge it and agree on giving this requirement a high priority.
• Sometimes stakeholders have very good reasons to assign a different priority, because they know something the other stakeholders don't know.
  It is interesting of cource to bring this knowledge into the discussion. If the reasoning is sound, other stakeholders will most of the time be willing to adjust their priorities. This results in the stakeholders as a team assigning new priorities.
• After most of the requirements are assigned their priorities, some are left. As all stakeholders see now how far they have come already in harmony with the other stakeholders, they are already bought in into the until now assigned priorities. This makes it extremely difficult for them to make a real issue on discussing the priorities of the remaining requirements. 

The above procedure is extremely interesting for the project lead, as she only has to facilitate this meeting and can leave the arguing for the participating stakeholders. Now that is a much better situation than (as a project lead) coming up with your own suggested prioritation which you have to defend against all other stakeholders!

Sometimes life is not as easy as described above. In projects continuously reporting on earned value, project leads might be tempted to try something else.

Scott Sehlhorst, a long time blogger whose blog at Tyner Blain I'm following for years now, recently wrote about Plan Your Next Sprint By ROI: Part 1. Basically, in this post Scott devided the Value of requirements by their Cost to give the Return on Investment. Seemingly an other fantastic way to do your planning, but their were some flaws. Luke Hohman stated that "Prioritizing a Product Backlog for ROI is a fool’s errand".

The whole discussion between Scott and Luke is very educating, I suggest you all read it and learn from it!