The best way to avoid losing the benefit is to write benefit-driven stories.

  • For this benefit, as a user role, this capability I need.

The key is to lead with the benefit — since folks won’t forget to include the capability.
Of course, Yoda phrasing gets pretty annoying pretty quick. Here’s an actual user story of mine from an internal RFC:

  • To make the product easier to use, as a subscriber, you want to activate only the features that you are using, and hide unused features.

Very easy to read, and it keeps the important bit front-and-center: ease of use.
Some folks refer to this sort of thing as “Feature Injection”.
For more, see

Do you work from user stories? Do you sometimes find yourself scratching your head, and wondering why? Do you think benefit-first user stories would help you design better software?

Ted Husted is a Kaizen Squad developer on the Nimble AMS product crew. “We make the good changes that create a great product.”