Brad Storm’s Lofty Thoughts

Two practices from two different methodologies: user stories are an emphasis in extreme programming, while features is the mainstay in feature driven development. They both present strength and weaknesses. But aren’t they really related?

User Stories are written ’stories’ that defines what is to be made. These stories will in many ways replace any requirement documents. The story is written by the customer / stakeholder, maintained “just the right size” (each story is independent but small enough to be completed within an iteration) and is written in whole sentences, keeping an active voice.

Features are defined in Feature Driven Development as a result of the requirement specification. A feature consist in the form of action-object-result

However, XP’ers will maybe state that features is a step back to BRUF (big requirements up front) where all requirements are written down in detail before they are implemented, while FDD’ers will say user stories are too informal, resulting in impreciseness when the stories are converted to code.

However, let’s do a little experiment by combining these two practices.

Ticket ordering: Let’s say we have a ticket ordering system. By doing a domain walkthrough with the customer, we establish the following user stories:

1. The user should search for available tickets based on preferences. The most suitable tickets should be presented first.
2. The user should be able to pick as many tickets he wants from any available type before placing the order.
3. The user must confirm the complete order before it’s placed, along with all needed input data.

Now, from these stories we can establish that story 1 and 3 are dependent on each other and should be contained. There’s simply no business value in presenting tickets for sale without handling the ticket ordering. The second user story may be an extension to #1 and therefore could be placed in the back-log.

We then have:

1. Through a search, the user should be presented the best available tickets based on input preferences. The order must be confirmed by the user before it’s placed.
2. The user should be able to pick as many tickets he wants from any available type before placing the order.

Now, as XP’ers, we’re satisfied with these stories. They give an overall view of what this part of the system should do. The details will be handled through communication during implementation (we have, after all, an on-site customer).

However, as FDD’ers, we’re not quite happy. We need to work some more with these stories. Let’s see if we can model them to features, according to the

1. search for preferred tickets
2. Sort tickets to list according to preferences
3. Get paymentinformation from user
4. confirm ordered ticket
5. place order on ticket

Clearly we see this is much more detailed than the user story. Notice the first word in each sentence is a verb defining an action. Still there’s a need for clarity:

• What are preferences?
• What kind of information is needed from the user to place the order?

Like XP, these are details that can be captured during implementation.
However, with these features we have a more clear view of the model, and what needs to be implemented:

• Entity* User { (user information)
  }
• Value object** Preferences {(preference types}
• Aggregate*** Tickets {Ticket: array}
• Service**** TicketManager
• TicketManager.Search(Preferences): Tickets
• Tickets.Sort(Preferences)
• User.StorePaymentInfo ( … )
• Ticket.Confirm()
• Ticket.PlaceOrder() or TicketManager.PlaceOrder(Ticket)

Now, based on our testdriven approach, we can easily model our unit tests to the domain-model. If our customer believes these tests are sufficient for his ticket ordering system, then we’re home safe!

• TestTicketSort
• TestTicketConfirm
• TestTicketPlaceOrder
• TestTicketSearch

So what to make of this?

• Extreme programmers skips the detailed step of features, but jumps straight to test modelling
• FDD’ers analyse the stories more in detail. Note that unlike user stories, features are not always independent but the total sum of a feature should equal the implementation of a user story. Therefore, prioritizing features must be done not only after desire but also with dependency in mind (we need to gather user information before placing the order, for instance).
• Keep in mind that this feature modeling is only done within each story set (in this case, ticket ordering was part of a larger promoting system. The features were modeled only before implementing this set of stories).

What do you think? Is it worth doing the extra feature step or is this a step back to waterfall (analyze after requirements)?
B-)

[notes:]

*: Entity is an object where there’s need to identify one instance from another.

** Value Object: An object defined by its properties. The instance is not important, only it’s members.

*** Aggregate: An object holding a reference to other objects in order to make it complete

**** Service: an object doing an operation that doesn’t fit into any domain model

Definitions from Domain Driven Design by Eric Evans.