On a few of the Agile lists, Paul Arrowood asked: "How does Agile address a conventional Risk Log? I wouldn't call these 'blocked items' (aka issues). But more or less the [Scrum Master's?] watch list for things that could go awry (content not fabricated, new/unfamiliar technology, geographically dispersed team, interdependence with another project, etc)." I wrote an answer, and liked it well enough to put it here.

Managing Risk

XP’s planning is similar to Scrum’s, though XP planning reportedly originates in something Kent Beck learned from Jon Hopkins. XP planning, as it was taught to me, and as I teach it, is very like what we find in Mike Cohn’s book, which of course goes far beyond the Scrum basic practice.

One part of what we used to do was to sort stories by value and risk in deciding what to do, bringing risky stories forward and working on them long enough to assess the risk. In a way, that’s what happens now, but not because we sort by risk. I’ll come back to that below.

Part of what I was taught and teach was to estimate all stories, and to insist that all stories be small enough so that the team thought they could do them in no more than three weeks of a couple of programmers’ time. (Teams all over are now breaking stories down to more like a couple of days, and that’s what we teach now. It seemed important to get out in front of the parade.)

So rather than accept the wide range of estimates that some folks suggest, the 1,2,4,8,16,32 or the 1,2,3,5,8,13, I now teach teams to use a range of just 1, 2, and 3. That has an interesting effect: a risky story (that is, a story that is impacted by some item one might put on a risk log) cannot be estimated as a 1, 2, or 3!

Instead, the team will say something like “Well, if C# has the same kind of morphilation facilities as Java, then this will be a two. But we don’t know if it does or not. If we have to write a morphilation library, this card could be a thirty or more.”

But we are required to estimate all stories. To estimate this one, we must assess the morphilation risk and then either score this story as a two, or write new stories addressing building the morphilation facilities.

So the customer finds business value in knowing whether his story is a two or a thirty, and writes a story (not a technical task) that says “Assess C# morphilation facilities and estimate stories X, Y, Z, …” The business value, of course, is improved knowledge of how long the project will take, which is very high value indeed.

Bottom line: a risk that has not been addressed is a story that has not been written. That story has high business value. Write it, and put it on the backlog.