From RAD Lab

Contents 1 Epics 2 Compound 3 Complex 4 Implementation Details 5 Good Examples

Epics

• A user can find a job
• A user can purchase a product
• A user can offer a service
• A user can search for houses

These are all epics and need to be reduced down to smaller managable stories. These fail a few points in INVEST. The can't be estimated and they aren't small. The other problem with epics is they can't be prioritized by the customer. When deciding what to include and what to exclude in a release, it is necessary to choose which stories to include. Epics are often too chunky to make such judgements.

Compound

• The user can add, update, and delete items from their project

This is best broken down into three separate stories:

• The user can add items to their project
• The user can update items in their project
• The user can delete items from their project

Sometimes it is hard to determine since these may not seem completely independent. Often compound stories may imply more reuse than is possible and may impair accurate estimation of the complexity of the combined story.

Complex

• A user can access the web site using a web services interface
• The user can use a CORBA interface to retrieve the account balance

If you've never used a technology or the domain your trying to model is very complex it is best to break these stories into two pieces. The first is called a spike and the second is the refined story or stories once the spike is complete. The spike is a brief timeboxed (limited) exploration to determine how complex the entire feature is to implement. The object is to experiment with the technology or do just enough work so you can estimate the rest of the story.

Once the spike is complete, the original story can be estimated and possibly broken down into additional stories depending on what was discovered.

Implementation Details

• The application must be written in Ruby
• The user will click a button 32px wide to save their profile
• The user will fill out a form that will have provide a drop down list of choices for each category. The categories will be one of the following: Business, Personal, Other.

Try to keep UI detail out of the stories unless absolutely necessary. Don't constrain your implementation options unless the customer has required that a certain platform be used or there are hard constaints that may impact planning. If you have multiple option on how to implement a feature, write the story to allow as many as possible.

Good Examples

• A user can change the default credit card used for purchase
• The user can export data in XML
• The user can select an "Export to XML" feature
• The user will be prompted to save their work if they haven't saved it for 15 minutes
• The user can undo up to 50 commands
• The user can run the applicaiton on Windows XP, Mac OS, and Linux
• The user can pay for a product with a credit card (In the notes you can add the expected card types).