This page is part of AtsGoesExtreme and the AtsDiary. See also AtsCards. ----- The PlanningGame describes ways for managing story risk, but I don't really care for it. I'm currently using that risk indicator purely to indicate the risk involved in ''estimating'' the story. The problem with putting risk on the story is that it doesn't provide enough information, and high risk stories don't stand out from normal stories. Also, risks that don't involve stories aren't covered at all. I'm a big fan of SteveMcConnell's TopTenRisks BestPractice as described in RapidDevelopment. As with many things, I'm finding that 3x5 IndexCard''''''s are ideally suited to this approach. In the first phase of ATS, I kept a risk management document, but I had trouble keeping it up to date because it was a Word document and it was kept in revision control. I would think of risks when I was away from my computer, or just didn't want to be interrupted. Later, I assigned a RiskOfficer to manage the risks, and I'd call him up when I had an idea. Those risks were never documented, and I imagine it was because he didn't want to document the risks for the same reason I didn't, with the added bonus of being annoyed about being interrupted. I haven't made many risks cards yet, but I'm hoping that using IndexCard''''''s will allow me to spontaneously write down risks as they occur to me, since I carry blank cards and a pen with me everywhere. Since they're on cards, I can quickly sort through them and prioritize them as issues change. And having them stacked up on the corner of my desk means that every so often I see them and remember to review the risks of the project, something that I let lapse in the initial phase. ----- ATS risk cards say "RISK" in block letters in the center top of the card on the ruled side. That's followed by the probability of the risk, the cost of the risk in time if it occurs, and the cost adjusted for probability. Below this is a "Manage:" line that describes approaches for managing the risk. Here's some examples: ----- [Unnamed] may have to leave to take care of [issue]. Probability: 60%; Cost: 1 day/wk + Probability: 100%; Cost: 7 hrs/wk Overall: 5 hrs/wk + 7 hrs/wk = 1 1/2 days/wk Manage: Replace [unnamed] with another developer. ----- Problems with XP. Probability: 50%; Cost: 1-2 weeks; Overall: 1 week Manage: Continually question XP practices. If something isn't working, stop immediately and revert to known good practices. Don't try anything that can't be reversed easily. ----- [Unnamed] is only person who can take care of urgent [other product] issues. He could be interrupted to work on [product]. Probability: 75%; Cost: 4 hrs/wk + Probability: 20%; Cost: 2 days/month Overall: 3 hrs/wk + 1 hr/wk = 4 hrs/wk Manage: Can [unnamed] work on [product] after hours? How about passing the work to another developer? [Note: "unnamed" is paid for overtime, so asking him to work after hours isn't as heartless as it sounds.]