Stripping User Stories for Incremental Development

Title: Stripping User Stories for Incremental Development
Type: Rules
Status: final
Version: 2007-09-03

Gist: explain how to strip down (thin) user stories in order to have more, smaller user stories instead of few, large ones. This is a way to simplify planning releases, as core features can be added to the product earlier than the nice-to-have features. However, keep in mind that product users might like the product for its nice-to-have features.

Note: I find this kind of technique very valuable when being pressed to release. It is relatively easy to apply AND easy to argue about: "with this little time left, we can only provide the really necessary things." My managers liked the idea of getting the basic stuff, but being sure that they will get it far better that the usual "we will do it" and "oh, we couldn't do it" afterwards.
Note: Have you noticed how frequently used yet odd the term "really necessary" is?

Source: Jeff Patton (Agile Development Outside-In), some minor adjustments from my point of view. Thanks to Scott Selhorst for bringing this stuff to me.

R1 Necessity: Find the basic characteristics (course of event) of the user story that is absolutely necessary for the user. It may not be very comfortable, safe, flexible. Make it an own user story. You might want to mark it "Necessities".

R2 Flexibility: Find all options in the original user story that might make the feature more applicable in different situations. Make a user story each. You might want to mark it "Useful options".
Note: There really is no point in combining independent options into one story just because you don't want to have "so many stories".

R3 Safety: Find all the little features that add to increased data quality, prevent inappropriate actions, prevent trouble downstream from the spot. Make an user story each. Sometimes it is easy to combine these kind of topics into one user story with one common business value, like "ensure data quality". This business value can also serve as a name tag.

R4 Comfort, Performance: Find things that make it easier for the user to use the product. Also consider the next occurrance of the user story in the user's life (like if I can save these settings now, I can use them again later). This is where Kano's exciters come in. Products win usability awards here. Add a user story each. You might want to mark it "Added Comfort" or "Improved Performance".