“Where do user stories come from?”

This is a question that I hear constantly from people new to agile development. Lots of places, is the stock answer. User stories — or features — really can come from everywhere, as anyone on the team may have a good idea and propose it. Another common answer to this question is the Story-Writing Workshop, which is a good technique for quickly collecting a diverse set of stories from many people. But when the team’s customer already has a decent idea of what he or she wants built, and no user stories have yet been collected, the Feature-Building Workshop becomes the sharpest tool in the shed.

This is also a great Iteration Zero activity.

Participants

The Feature-Building Workshop can be as formal or informal as necessary and can pull in a variety of different participants. The usual suspects are:

• The project manager (who is the workshop facilitator)
• The team customer (or product owner, or stakeholder, or domain expert, or whomever is the right person to identify a preliminary feature set)
• The tech lead (or a member of the delivery team most fluent in the domain area under discussion)

I try to keep the number of participants down to three for this particular activity. It really is very focused and too many participants can cause side conversations, unnecessary tangents, crackberry intrusions, and other distractions.

Input and Output

Typically, you use this technique to quickly define features for a project or initiative — for example, for a new application or significant updates to an existing application. The participants must have a good idea of what the application is meant to do or the problems it is meant to solve.

The result of this exercise is a map of features with dependencies that may be ready for estimation and prioritization. While still on the table or wall the map will look something like this:

These features may be kept on index cars, stacked, sorted, and set back in place.  They can also be entered into a project management system or a simple spreadsheet.

Activity

This workshop can be done on a table with index cards or a wall with post-it notes. I like the table better, because you can move the cards around faster and it is easier for three people to gather around, but either medium works just fine.

The activity takes only five simple steps:

1. Ask the team customer to identify the first independent feature — that is, a feature that may be built without any dependencies on any other features that may be discussed during the workshop. Write the name of this feature on an index card and set the card on the table. *Log in* may be a good first feature.
2. All participants should consider whether this feature really can be built independent of any other features. If earlier features are identified they should be written on index cards and set on the table below the original feature.
3. Continue adding features, either building on the existing features or adding one with no dependencies to the bottom tier.
4. Vet the stories as the meeting progresses. Are the dependencies lined up correctly? Could features be merged or split to make the entire structure clearer?
5. Write an ID for each feature on the left-hand corner of the index card. Write the ID’s of dependent features (other features upon which that feature depends) on the right corner.

That’s all you have to do. And you get a surprisingly useful set of initial features with which to begin estimation and planning.

Comments (0)

Write comment

Show/hide comment form