Further exploring the ways in which agile methods can be integrated with project workflow, here are some agile discovery exercises to help you assess the inherent risks and value propositions of your project.

If you’ve read our first installment in this series, you’ve got a product vision statement, stacks of single ideas on notecards (user stories) and you’ve been to MoSCoW and back, leaving the Ws behind. Perhaps you went over to a microbrewery for some celebratory IPA and rhapsodized long into the night about how Agile would revolutionize your business.

Agile Discovery: The Hangover

You’re probably going to be pretty confused when you come in late the next morning to stacks of cards with M’s, S’s and C’s on them. “Now what?” you ask yourself. “Am I ready to start building?”

Nope. Not even close, and that’s absolutely okay. One of the main ideas behind Agile development is that you can’t possibly know every detail about a project at the beginning. That said, here are a few more agile discovery exercises to help your team and especially your client get focused.

Exercise Four: Establish Value Viewpoints

Petri Heiramo defines a value viewpoint as “a clearly defined, overarching business goal.”

“These value viewpoints,” he says, “are specific to your release and will likely differ from one release to another. While the Product Owner is the final arbiter, some discussion will likely be useful before you start value estimating.”

You can apply this agile discovery exercise to a project you’re working on now, or continue with the previous post’s imaginary example: mybookshelf.com. For the purposes of this exercise, let’s go with two value viewpoints that will apply to a lot of interactive projects: “Users attracted” and “Users retained.”

Exercise Five: Play Poker

For this exercise you will need poker chips in at least two different colors (preferably green and red).

Part One: Value Estimation

Using the established value viewpoints from our previous exercises as your guide, put your chips on the user stories you feel are most valuable. Petri explains in slightly greater detail:

“You want to evaluate how each story contributes to these two goals (and ignore any other possible value dimension, e.g. revenue gained).”

1. Lay the cards out on a large table so everyone can see each card.
2. Disperse a limited amount (8-10) of green poker chips to each person on the team. The limited number will force you to spend your chips on the “most valuable” stories.
3. Each member of the team should disperse their chips on the upper right hand corner of the story cards they feel are the most valuable.
   NOTE: Do your best not to be influenced by the others. Scrum teams are cross-functional, self-organizing and self-managing. You’re on the team because your viewpoint counts.
4. When everyone has finished putting down their chips, discuss it for five minutes. Look for patterns and correlations between value and M’s (from the last exercise). You may be surprised. Feel free to move a few chips around.

Part Two: Risk Evaluation

Now that you’ve had fun with value, you must deal with risk. For the purposes of this exercise, risk is defined as any sort of risk, business or technical. However, the risk should be applied only to each individual user story and not to the project as a whole.

Repeat steps 2 through 4 using red chips.

5. When you have finished and have had a moment to reflect on where the chips fell, write the number of green chips and red chips on the top half of each card. Write the numbers side by side on the right hand corner.

But What Does it Mean?

You have now four categories of cards.

• high value / high risk
• high value / low risk
• low value / low risk
• low value / high risk

You might think that you should focus preliminary development on high value / low risk items. Sure, get off to a good start, do things that are easy, get everyone feeling great about everything and build confidence! Not so fast.

Scrum is all about transparency. It seeks to expose risk and failure as well as value. Therefore, you’ll want to focus high value high risk PBIs first because by tackling these first, you’ll have a good sense of if and how this project is going to work right away. That’s a lot better than going through four months of development with your head in the sand only to find out in Beta that the whole thing is worthless.

Ken Schwaber, one of the architects of Scrum framework, put it best:

Scrum will help you fail in 30 days or less.