In a typical product development scenario, a client comes to you with an RFP or a list of all of the things their web app or website must do. Here are just a few of the must-have items from RFPs we’ve received recently:

• “It’s got to have drop downs!”
• “It’s got to work on an iPad.”
• “It needs video and social networking.”

We’ve all heard (or said) these things at one time or another. And of course, the big question, “How much will this cost?”

What you should say here is, “I don’t know.” Because unfortunately when you take this approach, you have no idea what you’re really building or why.

Agile to the Rescue

I recently took Petri Heiramo’s CollabNet Scrum Master Certification class in an effort to better understand how Agile development methodologies can be applied to our work with clients. Agile methodology is a project management approach that takes into account unpredictability, because its basic tools are designed to incorporate flexibility into development. We have experimented with some Agile approaches on past projects at Mightybytes, but we still struggled with workflows, communication, and figuring out when it’s appropriate for a project and when it isn’t.

I certainly didn’t learn everything there is to learn about Scrum (an alternative development approach that incorporates feedback into the creation process), and although I passed the exam, I don’t think I’d consider myself a Scrum master… yet. But I do think I can share a few Scrum-based tools that will help you and your clients get through a “discovery” process. So here’s the first in a series that you can start to practice right away.

Exercise One: The Product Vision Statement

For our first exercise, we’re going to write a product vision statement. This doesn’t have to be perfect. Follow this model (Geoffrey Moore’s template from Crossing the Chasm):

FOR (target customer)
WHO (statement of the need or opportunity)
THE (product name) is a (product category)
THAT (key benefit, compelling reason to buy)
UNLIKE (primary competitive alternative)
OUR PRODUCT (statement of primary differentiation)

Here’s an example that we used in our Scrum training:

FOR book lovers WHO LIKE TO discuss and share experiences with like minded-people mybookshelf.com (pulled directly from Petri’s example during training) IS AN internet community THAT allows people to create their own virtual bookshelf and discuss their opinions and experiences. UNLIKE traditional discussion forums, OUR SERVICE provides tailored features to their needs.

It’s not even that amazing, but you get the idea. Your mind is probably already thinking about what kinds of features mybookshelf.com should have or how you might write a similar product vision statement for one of your current clients.

Exercise Two: The Product Backlog

For exercise two, we’re going to create a product backlog. A product backlog is a list of everything that a product might do. According to CollabNet’s course materials, the product backlog is a “living series of requirements” and “represents the WHAT of the system” (rather than the how). It’s an easy exercise and extremely valuable to your clients. You’ll need a bunch of note cards, some pens, and everyone that may participate in the project, especially your client. The rules are simple:

1. One idea per card
2. Write the idea in the center of the card
3. The format for the ideas should be written as follows:
   • As a (user role), I can (do something) in order to or
   • (User role) can (do something) so that (some benefit or purpose)

That’s it. It’s that easy. Ideas can be as complex or simple as you like. They can be related or not, detailed or simple. Anything.

Try it with a project you’re about to start. Try it with an internal project you’ve been putting off because it seems like a scary giant living in the hillside and you’re afraid to awaken him again.

You will notice right away that the project becomes more user-focused rather than site-focused. You probably won’t find any cards saying:

“As a site visitor, I can look at drop-downs so that I can navigate the site.”

You may get to drop-downs eventually, but for now, you’re putting the focus where it needs to be, value.

When you’ve finished writing everything down, read them out loud to everyone and eliminate any exact duplicates.

Exercise Three: Go to MoSCoW

For this exercise you’ll need a large table or a big wall that you can stick things to and perhaps some large size post-it notes. Imagine your 1.0 release. You’ll definitely want your client there for this. Think about what that first release looks like and which cards will need to be a part of the 1.0 release, but don’t think too much. Write out separate post-it notes with M, S, C, and W on them and pin them to the wall or stick them to your large table.

• M means MUST be included for 1.0 release.
• S means SHOULD be included for initial release.
• C means COULD be included for 1.0 release.
• W means WON’T (at least for now) be included in the initial release.

Yes, it’s that easy. Now, start going through the cards and placing them under M, S, C, or W. Take about 15-20 minutes. If new ideas come up during this time, write more cards and include them in the fun. When you have finished going through all of the cards take a look one row at a time. Are all of the M’s really M’s? S’s really S’s? Just do the best you can to decide this, and don’t stress. You’ll be revisiting this again and again. When in doubt, push the items toward W. Once you’ve gone through everything, stack all of the W cards and remove them from your table/wall. Notice, the weight of uncertainty lifting away as you do this and make sure your client notices it too.

Have you tried similar approaches to this with projects? Did it work? Was it helpful? Let me know. I’d love to hear how this plays out for other organizations.

Keep all of the rest of your cards and let’s continue this process.