A customer usually has some vague idea about what he wants like “We need a web site showing our current deals, and we want our users to be able to book shuttles and special packages, as well as pay for their bookings online. We also want to offer a luxury service that includes travel to and from the spaceport and accommodation in a local hotel.”

It’s your job to translate these vague statements into some initial requirements. A requirement is a single thing that the software has to do.

Write down each requirement on an index card like this:

Title: Show current deals
Description: The web site will show current deals to Orion’s Orbits users.

A free virtual index cards site is scrumblr.

Meet with customers, potential users of the software, and other developers to clarify and get additional requirements.

Pose as many questions as possible:

• How many different types of shuttles does the software have to support?
• Should the software print out receipts or monthly reports? What should be on the reports?
• Should the software allow reservations to be canceled or changed?
• etc

Use brainstorming during meeting. Everyone has an equal say. No wrong idea.

Take four of the ideas from the bluesky brainstorm and create a new card for each potential requirements. Also try to come up with additional requirements of your own.

• Role playing. Imagine you are the software. Your customer attempts to tell you what she would like you to do. You write down each thing the software needs on your requirement cards.

• Observation. Watch (unobtrusively) how they conduct their business and figure out how the software will fit in.

A good requirement must be written from the customer’s perspective describing what the software is going to do for the customer.

A requirement should be written in the customer’s language and reads like a user story: a story about how their users interact with the software you are building.

A user story should

• describe one thing that the software needs to do for the customer
• be written using language that the customer understands
• be written by the customer
• be short. Aim for no more than 3 sentences.

A user story should not be a long essay, or use technical terms unfamiliar to the customer, or mention specific technologies.

These meeting sessions with the customer must be repeated as many times as necessary.

You are only ready to move on the next stage when you have no more questions and your customer is also happy that all the user stories capture everything they need the software to do.

The product of this stage is clear, customer-focused user stories.

At this point, we have answered the what question. Next we have to answer the when question.

Two steps process:

1. Add an estimate to each user story for how long you think it will take to develop (that is, design, code, test, and deliver) that functionality.

2. Add up all the estimates to get a total estimate for how long your project will take to deliver the required software.

Each developer in the team make estimates on their own. Then the team discusses their differences.

A user story with highly different estimates means there are hidden assumptions. The purpose of this step is to eliminate hidden assumptions. Go back to the customer for assumption-busting session.

When a user story’s estimate breaks the 15-day rule

• break your stories into smaller, more easily estimated stories.
• talk to your customer again about assumptions

This process is repeated until you get a consensus.