Visualizing Risk

From ThreeWeekProjectTurnaround:

Here are some ideas I have about some more simple things that might possibly work.

See them in bullet outline form at VisualizingRiskInPointForm.

Get a large bulletin board for the project. Get a bunch of index cards. Write the user stories from the requirements group on the cards. If a story is too big to fit on a card, get the user to agree with you about how to break it into multiple stories. If some small and closely related stories can reasonably be combined, do so. Put all the cards up on the bulletin board. Give the technical leads a half hour to review the cards and suggest any further splits or combinations needed so each card represents a single, cohesive user story. Get the users to agree to the cards or explain any revisions they need to these requirements.

Take a break.

Have the users prioritize the cards. Reorder the cards with top priority items at the top. Have the technical leads review the first priority group to give their opinion about whether all these items can be included in your three weeks. If so, decide which second to nth priority items will be scheduled for the release three weeks from now. If not, have the users decide which of the first priority items are most useful to them to have first.

If you have more cards than can be completed in the release for three weeks from now, have a scribe collect the cards, transcribe them, and put them on the project web site as "wish list for future versions, not scheduled yet".

You're done with the users for the morning.

Have the technical leads bring in their developers. Move all the cards to one side of the board, representing "high risk". Any developer who is confident that they can readily complete the software to fulfill the story, without having to learn anything new or to break a sweat, can move the card almost all the way to the other, "low risk" end of the board. (The far end of the board, "zero risk", is empty so far. Zero risk of development failure means that you've completed the software that passes the unit tests, and the user agrees that the software meets the requirement. Eventually all the cards for this release will be moved over there.) Any developer who thinks they can probably learn what is needed and do the job without too much trouble can move a card to the "medium risk" section.

Assign pairs of developers to conduct SpikeTests? on the high risk cards. (Start by asking for volunteers.) Any remaining developers are assigned to examine the "medium risk" items and to report back tomorrow on what would have to be done to move these to the "low risk" category.

Developers should spend some of their time writing unit tests that could only be passed by software that meets the requirements, and check the tests into the source control system.

Throughout the remainder of the project, as programmers complete work that lowers the risk of any particular card, move the card over as appropriate. Before moving a card, the development pair must check in code, documentation, and completed unit test results to the project web site. Developers will have the following priorities for the following three weeks: 1. Complete their current spike test, moving a high risk item to medium or low risk; OR realize that they're in over their heads on it, and request help. 2. Help others with their spike tests on request, or take over spike tests they could more readily complete. 3. Complete discovery of factors that reduce medium risk to low. 4. Research factors that would reduce medium risk to low. 5. Complete the unit tests for low risk code. 6. Complete low risk code that passes the corresponding unit test. 7. Check in and document low risk code which now is no-risk code. Look for the highest priority remaining item available on which the developer feels competent to contribute. If not all projects are adopted by volunteers, then starting with the highest risk projects, technical leads will use a random process to select among the most likely qualified developers.

I hope this is useful to you.

--ChrisBaugh

I had never seen risk-reduction dealt with so specifically before I read this. I actually read it half way through my story-writing session. While I ate lunch, I made some adjustments to my process to focus on risk-reduction where it was needed. Our customer tends to focus on what he can see, so some back-end stuff was not getting dealt with till we talked about risk. --CharliePoole