Why have a separate risk work item
The XP literature includes sorting work items by risk, although it doesn’t seem to be the current standard: William Wake’s is a well known Agilista that has included it in his early but very nice and still useful XP description in here. This February 2000 article is the basis for chapter 7 of his book, Extreme Programming Explored.
Notice that when the book was published in 2001, he cut out the topic on sorting work items by risk, and commented in his book that “[o]lder descriptions of release planning described the programmers sorting the stories by risk. Many teams don’t bother with this; most of the risk seems to show up in longer estimates, so the sorting is redundant. I recommend that a team think about ways to reduce risk in longer stories, but allow the customer to choose the order of the stories.”
That said, I agree that we don’t need to attach a Risk field in Stories/Scenarios. The ROM (Rough Order of Magnitude) field implicitly covers the overall impact anyway.
The Risk work item exists in MSF Agile and MSF CMMI for a different reason: to allow the management of “environmental” risks (including iffy architectural elements, and complexity underlying too many scenarios) other than straightforward “coding impact risks” such as in Bill Wake’s examples.
Here is an example of a typical environmental risk: say a USA-based (living in Dallas) employee in your team has a pending greencard receipt but has some work to do on site in France. He won’t be able to travel in case the receipt doesn’t arrive in time. So the project manager adds this risk to the backlog, and a contingency plan for this situation is crafted (“Plan B: work using LiveMeeting from Dallas, from 2:00 am to 11:00 am”), and a trigger is put in place (“if he doesn’t get the receipt by week X, cancel the trip and follow Plan B”).
So why add those types of risk work items to the backlog? Because Agile is about transparency and trust, and adding it there makes it clear to everyone in the team, including the customer, that there are risks that need to be handled along with requirements. It is the team’s responsibility to establish the Impact of a risk, but when it comes to establishing its Priority, MSF Agile is mute on that. I personally like to allow the customer to prioritize risks along with scenarios and QoS requirements, so she shares the team vision on why it is important to mitigate them.
Earlier SDLCs such as Evo from Tom Gilb, and Spiral from Barry Boehm were heavily risk-driven on all aspects, including technical risk. Initial versions of MSF (circa 1993) were allegedly the same, but in practice it followed the same approach that Bill Wake describes. MSF Agile is an offspring from XP with a MSF slant, so risk management is less emphasized but still present. On the other hand, MSF CMMI implements the standard MSFv4 process more fully to comply with CMMI.
All said, Risk work items have a place in software development, and if possible we should implement the minimum “Probability X Impact = Exposure” relationship, as it is the least common denominator when properly talking about risk management.
BTW, my favorite piece of canonical XP literature on Risk is the excellent article by Erdogmus and Favaro in chapter 43 of Extreme Programming Perspectives, where they describe XP as an “options-driven process”. It maps neatly to the “risk-driven management” thinking that drove the creation of the Team, Risk Management and Process Models from MSF 1.0 in 1993.
