Agile Requirements Gathering with User Stories
Just as in traditional projects, Agile projects start with basic requirements gathering. Knowing the goals of your end users and project stakeholders is the necessary first step to any successful project.
However, instead of trying to nail down all of the details up front, your goal in an Agile project is to capture just enough information to have a conversation with the customer at a later date. You capture this information as "user stories" -- short descriptions of the functionality in customer terms.
A user story is a placeholder and a promise to have a future conversation about the needed functionality. By delaying the detailed conversation until shortly before development, you can avoid some of the waste that is typical of projects where detailed requirements are gathered early, but become invalid before the work begins.
In addition, you may discover that certain requested features are no longer needed by the customer after a few months, and you'll have saved the cost and effort of a detailed analysis.
A useful structure for brainstorming user stories (although certainly not the only good one) is as follows:
As a [Type of User], [Function to Perform] so that [Business Value]
In practice, you might not actually write your stories exactly this way, but keeping this format in mind helps focus the story descriptions so that they stay customer and business value oriented instead of technical in nature.
For example, in a sales management system, some typical user stories might be:
- As a sales person, I want to add a new contact so that I can follow up later with prospects.
- As a sales manager, view new contacts added by salesperson, so I can track leads
- As a system administrator, add a new sales person so they can access the system
At the start of a project, you'll want to gather the key project stakeholders to brainstorm possible user stories at this level of detail. By elaborating all of the possible users of the system first, you can then determine what functionality each type of user might need.
It's perfectly fine if some of the user stories aren't uncovered in this first planning session. The key strength of Agile development approaches is the ability to incorporate new requests for functionality as they are discovered. This takes a great deal of pressure off of your customers, since they know they can change their minds if the business climate changes or if they forget something important.
Remember that the point is not to decide about how these stories can be implemented at this stage, it's just a first cut at understanding the scope of the system. Later, you'll prioritize these stories with your customers, and select a subset of these for your first release. You'll then choose an even smaller subset for your first iteration (a fixed length time period during which development will take place, usually 1 to 4 weeks).
It's during the iteration planning process that you'll have the more detailed conversations with your customers that clarify the issues. And even during development, it's critical to stay in close contact with the customers to be able to ask questions.
Capturing User Stories With ExtremePlanner
ExtremePlanner lets you enter user stories using just a name (no other information is required up front). You can enter a description at this point if it's appropriate. By default, new stories will be in the project backlog - they won't be scheduled for a release or iteration.
You can also import user stories from Excel (tab-delimited files) if you've been tracking features in a spreadsheet. ExtremePlanner lets you map the header columns of your spreadsheet to user story fields, so you can import almost any format.