Stripping User Stories for Incremental Development

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


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?

Rules and Notes

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".

Costs, Savings

<What does it take to implement those rules? What does it give?>

Side effects

<Is there anything that happend or will happen as one implements the rules? This relates to both wanted and unwanted effects ('unwanted' does not imply 'negative').>

Related Pages

rating: +1+x

If you want to know more about a topic, simply tag the article with a 'morePlease' or 'examplesPlease' tag!


Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License