Story Process

Here we track the User Stories created by the community. When you create a new user story, please use the "User Story" template, as it's important to understand and arrive at agreement on both the end-user's interaction/workflow, and the underlying exchange of data. Please be sure and name the user story using the pattern "[actor] [sends/receives] [content] to [actor]".

Each user story has a particular "status":

1. Draft - a work-in-progress, open to discussion and changes.
2. Proposed - when the author or other significant contributor to the page feels the page represents a complete user story, ready for the community to vote. No changes allowed except for spelling or other changes which don't affect the way the story works.
3. Peer Approved - when a Proposed story has been voted upon successfully.

What is a successful community vote? This is really up to this community to decide, but one common pattern used elsewhere, to avoid a design-by-committee problem, is to look for third-party endorsements by other community members (perhaps a minimum of 3 to 5), with no member issuing a "veto", over the course of some short range of time (say a week). Since a "veto" is so heavy, the veto-er is on the hook to explain what changes need to be made to address their concerns. Since the goal is to be agile and create a number of different user scenarios quickly, a veto should be relatively rare, and done strictly in the spirit of improving the user story rather than to block it entirely.

What makes for a good User Story? There are a number of good essays on this:

• Scott Ambler's Introduction to User Stories
• Six Features of a Good User Story - INVEST Model
• Wikipedia's page on User Stories

We've started with a different kind of template for ours, but we can still change that or elaborate on each user story before we settle down to vote and approve them. Let's discuss this on the Google Group and then bring the conclusion to this page.