I ran across Jeff Patton and learned of his Story Mapping concepts. They were the closest thing I have seen to what we preached and practiced at TogetherSoft under the banner of Feature-driven Development.
It's hard to put into words the nature of how I drive development by a domain model and features... as they are deeply intertwined. The major key is to develop client-valued features
I wrote a bit about it here: User Stories and FDD
But I have a great internal wiki that I wrote on writing features... issues... stories. I should turn it into a blog... But I will paste it here to start.
Proper decomposition of a feature set is the first step to breaking it down into manageable, visible bits of success.
The only real value that we can deliver is a fully functioning feature (and arguably, one that is sufficiently documented).
We do not want to break down issues in terms of technical layers (UI, Logic, Database). Customers can't typically use a partially-implemented feature. Developers can add technical sub-tasks as needed (these need not be verified).
We do want to break features down into "vertical" slices as much as possible, so that we can deliver a fully-usable, valuable feature.
Split Stories into Small Chunks
Features (stories, use cases, requirements) are simply small blocks of client-valued functionality (they might appear on a marketing brochure or a users manual, and they are things the customer is willing to pay for (smile), and things that can have bugs against them (sad)). Ideally, you decompose – or break down – larger stories into smaller chunks of functionality (makes it easier to show progress and get feedback more quickly).
Features can be written in a couple of different ways, two of my favorites:
<Role> <Action> <Context> (thanks to Joshua Kerievsky)
Salesman creates quote for a simple request
Salesman creates quote for a complex, large RFQ
<Action> the <result> <by | for | of | to> a(n) <object> (thanks to Peter Coad)
Change the default price for current item
Calculate the total of a quote’s items
We can group related features into a Feature Set. Here again, we can use a tip to help in naming the feature set:
<Action><-ing> a(n) <object>
Creating a Quote
Configuring a Quote Item
To group related Feature Sets, we can create an even higher organizing theme: Major Feature Sets. And once again, a common naming convention applies:
Product Item Management
None of these conventions are strict, but they do help to steer the names in a consistent manner. And we all know consistency is a quality unto itself, right?
Some articles for you: